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华章 科技 


技术 丛书 





Hadoop Internals: in-depth study of MapReduce 


Hadoop “N yt 


深入 解析 MapReduce 架 构 设 计 与 实现 原理 


HG MOF 


G) Ra T w it 社 


hina Machine Press 


= 
Dll 


为 什么 要 写 这 本 书 
读者 对 象 

如 何 阅读 本 书 
勘误 和 支持 


致谢 


第 一 部 分 “基础 篇 


BIE 
1.1 
12 
13 
1.4 
1.5 
1.6 
L7 

第 2 章 
al 
22 
23 
2.4 
23 
2.6 


阅读 源 代 码 前 的 准备 
准备 源 代码 学 习 环 境 

获取 Hadoop 源 代码 

搭建 Hadoop 源 代码 阅读 环境 
Hadoop 源 代码 组 织 结构 
Hadoop 初 体验 

编译 及 调试 Hadoop 源 代码 

小 结 

MapReduce 设 计 理 念 与 基本 架构 
Hadoop 发 展 史 

Hadoop MapReduce 设 计 目 标 
MapReduce 编 程 模 型 概述 
Hadoop 基 本 架构 

Hadoop MapReduce 作 业 的 生命 周期 


小 结 














第 二 部 分 “MapReduce 编 程 模型 篇 


第 3 章 
Sl 
3.2 
33 
3.4 
33 
3.6 


MapReduce 编 程 模型 
MapReduce 编 程 模型 概述 
MapReduce API 基 本 概念 
Java API 解 析 

非 Java API 解 析 
Hadoop 工 作 流 


小 结 


第 三 部 分 MapReduce 核 心 设计 篇 


第 4 章 
4.1 
4.2 
4.3 
4.4 
4.5 

第 5 章 
S 





Hadoop RPC 框 架 解 析 
Hadoop RPC 框 架 概 述 
Java 基 础 知识 
Hadoop RPC 基 本 框架 分 析 
MapReduce 通 信 协 议 分 析 
小 结 

作业 提交 与 初始 化 过 程 分 析 
作业 提交 与 初始 化 概述 











K 


32 
$3 
54 
55 

第 6 章 
6.1 
6.2 
6.3 
6.4 
6.5 
6.6 
6.7 
6.8 

第 7 章 
7.1 
T3 
?3 
7.4 
75 
7.6 
1 

第 8 章 
8.1 
8.2 
8.3 
8.4 
8.5 
8.6 


作业 初始 化 过 程 详解 
Hadoop DistributedCache 原 理 分 析 
小 结 
JobTracker 内 部 实现 剖析 
JobTracker 概 述 
JobTracker 启 动 过 程 分 析 
心跳 接收 与 应 答 

Job 和 Task 运 行 时 信息 维护 
容错 机 制 
任务 推测 执行 原理 
Hadoop 资 源 管理 

小 结 
TaskTracker 内 部 实现 剖析 
TaskTracker 概 述 
TaskTracker 启 动 过 程 分 析 
心跳 机 制 
TaskTracker 行 为 分 析 
作业 目录 管理 
启动 新 任务 

小 结 

Task 运 行 过 程 分 析 
Task 运 行 过 程 概述 
基本 数据 结构 和 算法 
Map Task 内 部 实现 
Reduce Task 内 部 实现 
Map/Reduce Task 优 化 
小 结 








第 四 部 分 “MapReduce 高 级 篇 


第 9 章 
3 
9.2 
95 
9.4 


Hadoop 性 能 调 优 
概述 
从 管理 员 角 度 进行 调 优 
从 用 户 角度 进行 调 优 
小 结 


第 10 章 ”Hadoop 多 用 户 作 业 调度 器 


10.1 
10.2 
10.3 
10.4 
10.5 


多 用 户 调度 器 产生 背景 
HOD 

Hadoop 队 列 管 理 机 制 
Capacity Scheduler 实 现 
Fair Scheduler 实 现 


10.7 小 结 
第 11 章 ”Hadoop 安 全 机 制 

11.1 Hadoop 安 全 机 制 概述 

11.2 ”基础 知识 

11.3 ”Hadoop 安 全 机 制 实现 

11.4 应 用 场景 总 结 

11.5 小 结 
第 12 章 下 一 代 MapReduce 框 架 

12.1 第 一 代 MapReduce 框 架 的 局 限 性 

12.2 下 一 代 MapReduce 框 架 概述 

12.3 Apache YARN 

12.4 Facebook Corona 

12.5 Apache Mesos 

12.6 小 结 
附录 A ”安装 Hadoop 过 程 中 可 能 存在 的 问题 及 解决 方案 
附录 B ”Hadoop 默 认 HITP 端 口号 以 及 HITP 地 址 
参考 资料 












= 
ll 


为 什么 要 写 这 本 书 




















其 是 FaceBook、 












































突然 之 间 ， 大 数据 一 下 子 就 “ 火 " 了 ， 开 源 软件 Hadoop 也 因此 水 涨 船 高 。 得 益 于 一 些 国 际 领先 厂商 ， 尤 
Yahoo! 以 及 阿里 巴巴 等 互联 网 巨头 的 现身说法 ，Hadoop 被 看 成 大 数据 分 析 的 ' 神 器 ”。IDC 在 对 中 国 未 来 几 年 的 预测 中 就 专门 提 
到 了 大 数据 ， 其 认为 未 来 几 年 ， 会 有 越 来 越 多 的 企业 级 用 户 试 水 大 数据 平台 和 应 用 ， 而 这 之 中 ，Hadoop 将 成 为 最 次 眼 的 “明星 ”。 











































































































尽管 Hadoop 整 个 生态 系统 是 开源 的 ， 但 是 ， 由 于 它 包 含 的 软件 种 类 过 多 ， 且 版 本 升级 过 快 ， 大 部 分 公司 ， 尤 其 是 一 些 中 小 
发 人 员 带 来 了 很 大 的 学 
《Pro Hadoop》、 





























型 公司 ， 难 以 在 有 限 的 时 间 内 快速 掌握 Hadoop 萤 含 的 价值 。 此 外 ，Hadoop 自 身 版 本 的 多 样 化 也 给 很 多 看 
习 负 担 。 尽 管 当前 市 面 上 已 有 很 多 参考 书籍 ， 比 如 《Hadoop: The Definitive Guide》、 《Hadoop in Action) , 
的 实现 细节 ， 比 如 JobTracker 实 现 、 作 业 调 度 器 



































{Hadoop Operations》 等 ， 但 是 ， 至 今 还 没有 一 本 书 能 够 深入 地 剖析 Hadoop 内 六 
考 网 络 上 一 些 零星 的 源 代码 分 析 的 文章 ， 自 己 一 点 一 点 地 阅读 源 代 
内 第 一 本 深入 剖析 Hadoop 内 部 实现 细节 的 书籍 。 
























































实现 等 。 也 正 因 如 此 ， 很 多 Hadoop 初 学 者 和 研发 人 员 只 能 参 
码 ， 缓 慢 地 学 习 Hadoop。 而 本 书 正 是 为 了 解决 以 上 各 种 问题 而 编写 的 ， 它 是 国 























本 书 以 Hadoop 1.0 为 基础 ， 深 入 剖析 了 Hadoop MapReduce 中 各 个 组 件 的 实现 细节 ， 包 括 RPC 框 架 、JobTracker 实 现 、 
介绍 了 MapReduce 各 个 组 件 的 内 部 实现 原理 ， 而 且 结合 源 代 码 进 



































TaskTracker 实 现 、Task 实 现 和 作业 调度 器 实现 等 。 书 中 不 仅 详 
行 了 深入 的 剖析 ， 使 读者 可 以 快速 全 面 地 掌握 Hadoop MapReduce 设 计 原 理 和 实现 细节 。 


























读者 对 象 











(1) Hadoop 二 次 开发 人 员 


























Hadoop 由 于 在 扩展 性 、 容 错 性 和 稳定 性 等 方面 的 诸多 优点 ， 己 被 越 来 越 多 的 公司 采用 。 而 为 了 减少 开发 成 本 ， 大 部 分 公司 
在 Hadoop 基 础 上 进行 了 二 次 开发 ， 以 打造 属于 公司 内 部 的 Hadoop 平 台 。 对 于 Hadoop 二 次 开发 人 员 来 说 ， 深 入 而 又 全 面 地 了 解 
Hadoop 的 设计 原理 与 实现 细节 是 修改 Hadoop 内 核 的 前 提 ， 而 本 书 可 帮助 这 部 分 读者 快速 而 又 全 面 地 了 解 Hadoop 实 现 细 节 。 






























































































































































(2) Hadoop 应 用 开发 人 员 




























































































如 果 要 利用 Hadoop 进 行 高 级 应 用 开发 ， 仅 掌握 Hadoop 基 本 使 用 方法 是 远 远 不 够 的 ， 必 须 对 Hadoop 框 架 的 设计 原理 、 架 构 和 
运作 机 制 有 一 定 的 了 解 。 对 这 部 分 读者 而 言 ， 本 书 将 带领 他 们 全 面 了 解 Hadoop 的 设计 和 实现 原理 ， 加 深 对 Hadoop 框 架 的 理解 ， 
提高 开发 水 平 ， 从 而 编写 出 更 加 高 效 的 MapReduce 应 用 程序 。 






















































































(3) Hadoop 运 维 工程 师 





























对 于 一 名 合格 的 Hadoop 运 维 工程 师 而 言 ， 适 当地 了 解 Hadoop 框 架 的 设计 原理 、 架 构 和 运作 机 制 是 十 分 有 帮助 的 。 这 不 仅 可 
以 使 Hadoop 运 维 人 员 更 快 地 排除 各 种 可 能 的 Hadoop 故 障 ， 还 可 以 让 Hadoop 运 维 人 员 与 研发 人 员 进 行 更 有 效 的 沟通 。 通 过 阅读 这 
本 书 ，Hadoop 运 维 人 员 可 以 了 解 到 很 多 其 他 书 中 无 法 获取 的 Hadoop 实 现 细节 。 












































































































































(4) 开源 软件 爱好 者 





























Hadoop 是 开源 软件 中 的 佼佼 者 。 它 在 实现 的 过 程 中 吸收 了 很 多 开源 领域 的 优秀 思想 ， 同 时 有 很 多 值得 学 习 的 创新 。 尤 为 值 
得 一 提 的 是 ， 本 书 分 析 Hadoop 架 构 设 计 和 实现 原理 的 方式 也 许 值得 所 有 开源 软件 爱好 者 学 习 和 借鉴 。 通 过 阅读 本 书 ， 这 部 分 读 
者 不 仅 能 领略 到 开源 软件 的 优秀 思想 ， 还 可 以 掌握 分 析 开 源 软件 源 代 码 的 方法 和 技巧 ， 从 而 进一步 提高 使 用 开源 软件 的 效率 和 质 
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如 何 阅读 本 书 


本 书 分 为 四 大 部 分 (不 包括 附录 》: 





























第 一 部 分 为 基础 篇 ， 简 单 地 介绍 Hadoop 的 阅读 环境 措 建 和 基本 设计 架构 ， 帮 助 读者 了 解 一 些 基础 背景 知识 。 
































第 二 部 分 为 MapReduce 编 程 模型 篇 ， 着 重 讲解 MapReduce 编 程 接 口 ， 主 要 包括 两 套 编程 接口 ， 分 别 是 旧 API 和 新 API。 
























































第 三 部 分 为 MapReduce 核 心 设计 篇 ， 主 要 讲解 Hadoop MapReduce 的 运行 时 环境 ， 包 括 RPC 框 架 、 客 户 端 、JobTracker、 
TaskTracker 和 Task 等 内 部 实现 细节 。 




















第 四 部 分 为 MapReduce 高 级 篇 ， 主 要 讲解 Hadoop MapReduce 中 的 一 些 高 级 特性 和 未 来 发 展 趋势 ， 包 括 多 用 户 作 业 调 度 器 、 安 
全 机 制 和 下 一 代 MapReduce 框 架 等 。 



































另外 ， 本 书 最 后 还 添加 了 几 个 附录 : 附录 A 为 安装 Hadoop 过 程 中 可 能 存在 的 问题 及 解决 方案 ， 附 录 B 为 Hadoop 默 认 HITP 端 











号 以 及 HITP 地 址 。 参 考 资料 中 包括 了 本 书写 作 过 程 中 参考 的 书籍 、 论 文 、Hadoop Jira 和 网 络 资源 。 



































如 果 你 是 一 名 经 验 丰富 的 资深 用 户 ， 能 够 理解 Hadoop 的 相关 基础 知识 和 使 用 技巧 ， 那 么 你 可 以 直接 阅读 第 三 部 分 和 第 四 部 
分 。 但 是 ， 如 果 你 是 一 名 初学 者 ， 请 一 定 从 第 1 章 的 基础 理论 知识 开始 学 习 。 












































勘误 和 支持 
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由 于 笔者 的 水 平 有 限 ， 加 之 编写 时 间 仓 促 ， 书 中 难免 会 出 现 一 些 错误 或 者 不 准确 的 地 方 ， 奶 请 读者 批 讨 
意 创建 了 一 个 在 线 支 持 与 应 急 方案 的 站 点 httpy/hadoop123.com。 你 可 以 将 书 
ALA AQ& ARE 













































































指正 。 为 此 ， 笔 者 特 
的 错误 发 布 在 Bug 勘 误 表 页 面 中 。 如 果 你 遇 到 问题 ， 
。 如 果 你 有 什么 宝贵 意见 ， 欢 迎 发 送 邮 件 至 























j， 我 将 尽量 在 线 上 为 读者 提供 最 满意 的 解答 
dongxicheng(Oyahoo.com， 期 待 能 够 得 到 你 的 真挚 反馈 。 
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其 至 专门 为 我 写 书 留 出 空闲 
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， 以 及 众多 热爱 Hadoop 的 朋友 们 ! 
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本 部 分 内 容 


阅读 源 代码 前 的 准备 

















MapReduce 设 计 理 念 与 基本 架构 





第 1l 章 ”阅读 源 代码 前 的 准备 


























一 般 而 言 ， 在 深入 研究 一 个 系统 的 技术 细节 之 前 ， 先 要 进行 一 些 基本 的 准备 工作 ， 比 如 ， 准 备 源 代码 阅读 环境 ， 措 建 运行 环 
境 并 尝试 使 用 该 系统 等 。 对 于 Hadoop 而 言 ， 由 于 它 是 一 个 分 布 式 系统 ， 且 由 多 种 守护 进程 组 成 ， 具 有 一 定 的 复杂 性 ， 如 果 想 深 
入 学 习 其 设计 原理 ， 仅 仅 进行 以 上 几 项 准备 工作 是 不 够 的 ， 还 要 学 习 一 些 调试 工具 的 使 用 方法 ， 以 便 对 Hadoop 源 代码 进行 调 
试 、 跟 踪 。 边 用 边 学 ， 这 样 才能 事半功倍 。 












































































































































本 章 的 编写 目的 是 帮助 读者 构建 一 个 “高 效 " 的 Hadoop 源 代码 学 习 环境 ， 包 括 Hadoop 源 代码 阅读 环境 、Hadoop 使 用 环境 和 
Hadoop 源 代码 编译 调试 环境 等 ， 这 主要 涉及 如 下 内 容 : 














口 在 Linux 和 Windows 环 境 下 搭建 Hadoop 源 代码 阅读 环境 的 方法 ; 



































口 Hadoop 的 基本 使 用 方法 ， 主 要 包括 Hadoop Shel 和 Eclipse 插件 两 种 工具 的 使 用 ; 




















口 Hadoop 源 代码 编译 和 调试 方法 ， 其 中 ， 调 试 方法 包括 使 用 Eclipse 远程 调试 和 打印 调试 日 志 两 种 。 


















































稼 虑 到 大 部 分 用 户 在 单机 上 学 习 Hadoop 源 代码 ， 所 以 本 章 内 容 均 是 基于 单机 环境 的 。 本 章 大 部 分 内 容 较为 基础 ， 已 经 掌握 
这 部 分 内 容 的 读者 可 以 直接 跳 过 本 章 。 
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1.1 准备 源 代 码 学 习 环境 
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对 于 大 部 分 公司 而 言 ， 实 验 和 生产 环境 中 的 服务 器 集群 部 署 的 都 是 Linux 操 作 系统 。 考 虑 到 Linux 在 服务 器 市 场 中 具有 统治 地 
位 ，Hadoop 从 一 开始 便 是 基于 Linux 操 作 系统 开发 的 ， 因 而 对 Linux 有 着 非常 完美 的 支持 。 尽 管 Hadoop 采 用 了 具有 跨 平台 特性 的 
Java 作 为 主要 编程 语言 ， 但 由 于 它 的 一 些 功能 实现 用 到 了 Linux 操 作 系统 相关 的 技术 ， 因 而 对 其 他 平台 的 支持 不 够 友好 ， 且 没有 进 










































































行 过 严格 测试 。 换 名 话说， 其 他 操作 系统 Widows) 仅 可 作为 开发 环境 上 ， 不 可 作为 生产 环境 。 对 于 学 习 源 代码 而 言 ， 操 作 
系统 的 选择 显得 不 是 非常 重要 ， 读 者 可 根据 个 人 爱好 自行 决定 。 本 节 以 64 bitLinax 和 32 bit Windows 两 种 操作 系统 为 例 ， 介 绍 如 何 
在 单机 上 准备 Hadoop 源 代码 学 习 环境 。 

















1.1.1 基础 软件 下 载 























前 面 提 到 Hadoop 采 用 的 开发 语言 主要 是 Java， 因 而 搭建 Hadoop 环 境 所 需 的 最 基础 的 软件 首先 应 该 包括 Java 基 础 开发 包 JDK 和 
Java 编 译 工 具 Ant。 考 虑 到 源 代 码 阅读 和 调试 的 便利 性 ， 本 书 采用 功能 强大 的 集成 开发 环境 Eclipse。 此 外 ， 如 果 读 者 选择 Windows 
平台 搭建 学 习 环境 ， 还 需要 安装 Cygwin 以 模拟 Linux 环 境 ， 这 是 因为 Hadoop 采 用 Bash Shell 脚 本 管理 集群 。 搭 建 Hadoop 阅 读 环境 需 
要 的 各 种 软件 以 及 下 载 方式 如 表 1-1 所 示 。 
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% 1-1 搭建 Hadoop 阅读 环境 所 需 的 各 种 软件 及 下 载 方式 
软 件 下 载 网 址 推荐 版 本 说 明 
http://www.oracle.com/technetwork/ ain Windows 和 Linux 的 安装 
JDK java/javase/downloads/index.html 1.6 以 上 包 不 同 
7 f Windows 和 Linux 使 用 相 
Ant http://ant.apache.org/bindownload.cgi |1.6.0 以 上 Bre ee 
Cygwin http://www.cygwin.com/ 最 新 版 本 只 有 Windows 平台 需要 


Ji 7 i H a 4 
Eclipse http://www.eclipse.org/downloads/ Galileo 或 者 Helios 版 本 9 eae 和 Limx 的 安装 
a. vn 


[1] 截至 本 书 结 稿 时 ，Apache Hadoop SVN 中 已 经 出 现 了 针对 Windows 操 作 系 统 的 分 支 ， 有 具体 见 
http//svn.apache.org/repos/asfhadoop/common/branches/ 下 的 branch-1-win 和 branch-trunk-win， 且 Hortonworks 公 司 发 布 了 Windows 安 装 版 
本 ， 具 体 见 httpy/hortonworks.conypartners/microsoft/ 


R EŠ, Indigo% A EIRA Hadoop Eclipse 插件 可 能 存在 兼容 问题 。 




















1.1.2 ”如何 准备 Windows 环 境 





本 小 节 将 介绍 如 何 准备 Windows 下 的 Hadoop 学 习 环境 ， 包 括 JDKE、Ant、Cygwin 和 Eclipse 等 基础 软件 的 使 用 方法 。 本 小 节 假 设 


用 户 的 软件 安装 目录 为 D\hadoop， 且 最 终 安装 完成 的 目录 结构 为 : 








D: \hadoop 
|ļ— apache-ant-1.7.1 
HF cygwin 
L— Java 
L—jdk1.6.0 25 


1.JDK 的 安装 


也 | 








用 户 下 载 的 安装 包 为 jdk-6u25-windows-i586.exe， 直 接 双 击 该 安装 包 将 JDK 安 装 到 DMNhadoopJava\ 下 ， 然 后 设 配置 环境 变 
JAVA HOME, CLASSPATH, PATH (不 区 分 大 小 写 )， 方 法 如 下 。 








(1) 配置 JAVA HOME 














如 图 1-1 所 示 ， 在 Windows 桌 面 上 ， 右 击 “ 计 算 机 ”图标 ， 然 后 在 弹出 的 快捷 沫 单 中 依次 选择 "属性 一 “高 级 系统 设置 一 “环境 





1 [oe 


量 "” 命 令 ， 然 后 在 系统 变量 栏 ， 单 击 “ 新 建 按 钮 ， 在 弹出 的 对 话 框 中 的 “变量 名 ”文本 框 中 填写 JAVA_ HOME， 在 ' 灾 量 值 ”文本 术 
S45 DAhadoop\Java\jdk1.6.0 25， 然 后 单 击 ' 哨 定 " 按 钮 。 












































变量 名 N) JAVALHOME 
变量 值 om D: \hadoop\Java\jdkl.6.0_25 





值 


Windows_NT m 
D: \website\PHP\;C: \Program File... 
.COM;. EXE;. BAT;.CMD;.¥BS;.VBE;.... 
Ti: \wehsiteSPHPS 


+ 

















1-1 Windows 环 境 下 设置 JAVA_HOME 环 境 变量 





(2) 配置 CLASSPATH 





参考 JAVA_HOME 另 建 一 个 系统 变量 ， 变 量 名 为 CLASSPATH， 变 量 值 为 : 











.; SJAVA_HOME%/lib/dt.jar; %JAVA_HOME%/lib/tools.jar; 








(3) 配置 PATH 








NI 
7 





PATH2¢ CATE, pa a AN. FEAR EE PAS PN: 














SJAVA_HOME%/bin; *JAVA_HOME%/jre/bin 














经 过 以 上 配置 ，JDK 已 经 安装 完毕 ， 可 在 DOS 窗 口中 输入 命令 ava-version" 以 验证 是 否 安装 成 功 。 如 果 输 出 以 下 内 容 ， 则 说 
明 安 装 成 功 : 














java version"1.6.0_25" 
Java (TM) SE Runtime Environment (build 1.6.0 25-b05) 
Java HotSpot (TM) Client VM (build 20.6-b01, mixed mode, sharing) 





2.Ant 的 安装 








假设 下 载 的 安装 包 为 apache-ant-1.7.1-bin.zip， 直 接 将 其 解压 到 工作 目录 Di\hadoop\ 下 ， 并 添加 新 的 环境 变量 ANT HOME， 设 置 
其 值 为 D\hadoop\apache-ant-1.7.1， 同 时 在 环境 变量 PATH 后 面 添 加 如 下 内 容 : 



































; SANT HOMES\bin 











经 过 以 上 配置 ，Ant 已 经 安 
安装 成 功 : 








装 完毕 ， 可 在 DOS 窗 口中 输入 命令 “ant-version 以 验证 是 否 安装 成 功 。 如 果 输 出 以 下 内 容 ， 则 说 明 





Apache Ant version 1.7.1 compiled on June 27 2008 





3.Cyewin 的 安装 


C1) 安装 Cygwin 














双击 下 载 的 Cyegwin 的 安装 包 setup.exe， 一 直 单 击 “ 下 一 步 " 按 钮 ， 直 到 出 现 如 图 1-2 所 示 的 界面 ， 在 “Net 盖 栏 中 选中 OpenSSH 相 
关 软 件 包 ， 会 出 现 如 图 1-3 所 示 的 界面 ， 然 后 单 击 “ 下 一 步 ” 按 钮 ， 此 时 系统 开始 在 线 下 载 并 安装 Cygwin 环 境 (时 间 比 较 长 》。 




















Œ Cygwin Setup - Select Pack: 


Select packages to install 


Search [Cear] © Keep @ 


Category 





Package 
KDE 4¥ Default 
Libs 4¥ Default 
Mail £f Default 
Math 4¥ Default 
Minge 4¥ Default 
Perl 4¥ Default 


4 | alila 








Hide obsolete packages 








图 1-2 Windows 环 境 下 通过 Cygwin 安 装 OpenSSH 一 一 单 击 “Net 盖 栏 





© keep @Cur ©Ep [View| Category 


Category Bes E LA ES Package 
nc: Netcat with IPv6 Support 


neftp: An improved FTP client 


nfs-server: Universal HFS server. 

mrss: A neurses-based RSS reader 

nttep: Hew test TCP program 

openldap: Lightweight Directory Access Protoc 
openldap-devel: Lightweight Directory Access 
openssh: The OpenSSH server and client progra 
openssl: The OpenSSL base environment 
perl-Net-Libproxy: Proxy configuration manage 
ping: A basic network tool to test IP network 


planet: Flexible RDF, RSS and Atom feed aggre ~ 
上 














图 1-3 Windows 环 境 下 通过 Cygwin 安 装 OpenSSH 一 一 选中 OpenSSH 软 件 包 


(2) 安装 并 启动 sshd 服 务 








pail 





pari 要 通过 SSH 发 送 命 令 启 动 相关 守护 进程 ， 为 此 需要 安装 sshd 服 务 。 安 装 sshd 服 务 的 方法 是 ， 以 管 型 








身份 打开 Cygwin 命 令 当 《〈 右 击 运行 图 标 ， 单 击 “ 以 管理 员 身 份 运行 ? 俞 令 )》 ， 然 后 输入 以 下 命令 





ssh-host-config 





接着 ， 按 照 命 令 行 中 的 提示 进行 安装 ， 有 具体 如 图 1-4 所 示 。 





sh-host~—conf ig 
: Overwrite existing /etc/ssh_config file? “yes/no> yes 
Creating default /etc/ssh_config file 
Overwrite existing /etc/sshd_config file? “yes/no? yes 
Info: Creating default /etc/sshd_config file 
t Info: Privilege separation is set to yes by default since OpenSSH 3.3. 
Info: However, this requires a non-privileged account called ’sshd’. 
Info: For more info on privilege separation read /usr/share/doc/openssh/READ 
-privsep. 
* Query: Should privilege separation be used? yes/no? yes 
Info: Note that creating a new user requires that the current account have 
Info: Administrator privileges. Should this script attempt to create a 
Query: new local account ’ sshd’? <yes/no> yes 
Info: Updating /etc/sshd_config file 


Warning: The following functions require administrator privileges? 


Query: Do you want to install sshd as a service? 
Say “no” if it is already installed as a service) yes/no) yes 
Query: Enter the value of CYGWIN for the daemon: [] ntsec。 





图 1-4 Windows 环 境 下 通过 Cygwin 安 装 sshd 服 务 





安装 完毕 后 ， 输 入 以 下 命令 启动 sshd 服 务 : 





net start sshd 





4.Eclipse 的 安装 

















Eclipse 官网 提供 的 Eclipse 版 本 均 是 免 安 装 版 ， 直 接 将 下 载 的 压缩 包 解压 到 'DxhadoopY' 下 即 可 使 用 。 




















1.1.3 ”如 何 准备 Linux 环 境 


本 小 节 将 介绍 如 何 准备 Linux 下 的 Hadoop 学 习 环境 。 搭 建 Linux 学 习 环境 需要 安装 JDK, Ant 和 Eclipse 等 软件 。 本 书 以 64 bit Ubuntu 














为 例 ， 介 绍 安装 这 些 软件 的 方法 ， 最 终 安 装 完成 的 目录 结构 为 : 





ROOT 
— home 


| L— dong 
| lL— eclipse 
L—usr 
L— lib 
}— apache-ant-1.7.1 
= jvm 
L— jdki.6.0 25 


1.JDK 的 安装 与 配置 


一 般 而 言 ，Ubuntu 系 统 会 自 带 JDK， 如 果 没 有 或 者 版 本 不 符合 要 求 ， 可 按 以 下 步 又 进行 安装 : 





步骤 1 安装 JDK。 将 下 载 的 .bi 文件 复制 到 Linux 的 某 个 目录 下 ， 比 如 /usrlibjivny 下 ， 然 后 在 Shel 中 执行 以 下 命令 为 该 文件 添加 


可 执行 权限 : 








chmod+x/usr/1ib/jvm/jdk1.6.0 25.bin 





然后 执行 以 下 命令 安装 JDK: 





sudo/usr/1ib/jvm/jdk1.6.0 25.bin 











之 后 将 会 出 丙 
此 ，JDK 已 安装 完毕 ， 下 面 进行 配置 。 



































步骤 2 配置 JDK。 修 改 /etc/profile 文 件 ， 在 里 面 添 加 以 下 内 容 : 








安装 信息 ， 直 至 屏幕 显示 要 求 按 下 回 车 键 。 此 时 按 下 回 车 键 后 ， 会 把 JDK 解 压 到 文件 夹 jdk1.6.0 25 中 。 


z= 


Ty 








export JAVA_HOME=/usr/lib/jvm/jdk1.6.0 25 
export PATH=$PATH: $JAVA_HOME/bin 
export CLASSPATH=SCLASSPATH: SJAVA_HOME/lib: $JAVA_HOME/jre/lib 


























输入 以 下 命令 让 配置 生效 : 














source/etc/profile 














步骤 3 ”修改 默认 JDK 版 本 。Ubuntu 中 可 能 会 有 默认 的 JDK， 如 openjdk， 因 而 我 们 需要 将 自己 安装 的 JDK 设 置 为 默认 JDK 版 





本 ， 执 行 下 面 代 码 : 





sudo update-alternatives--install/usr/bin/java java/usr/lib/jvm/jdk1.6.0_25/bin/java 300 
sudo update-alternatives--install/usr/bin/javac javac/usr/lib/jvm/jdk1.6.0 25/bin/javac 300 
sudo update-alternatives--install/usr/bin/jar jar/usr/lib/jvm/jdk1.6.0 25/bin/jar 300 

sudo update-alternatives--install/usr/bin/javah javah/usr/lib/jvm jdk1.6.0 25/bin/javah 300 
sudo update-alternatives--install/usr/bin/javap javap/usr/lib/jvm/jdk1.6.0 25/bin/javap 300 





然后 执行 以 下 代码 选择 我 们 安装 的 JDK 版 本 : 








sudo update-alternatives--config java 








步骤 4 验证 JDK 是 否 安装 成 功 。 重 启 Shel 终 端 ， 执 行 命令 java-version"。 如 果 输 出 以 下 内 容 ， 则 说 明 安 装 成 功 ; 





java version"1.6.0 25" 
Java (TM) SE Runtime Environment (build 1.6.0 25-b06) 
Java HotSpot (TM) Client VM (build 20.0-b11, mixed mode, sharing) 





2.Ant 以 及 Eclipse 的 安装 


C1) 安装 与 配置 Ant 








首先 解压 下 载 包 ， 比 如 解压 到 文件 /usr/lib/apache-ant-1.7.1 目 录 下 ， 然 后 修改 /etc/profile 文 件 ， 在 里 面 添 加 以 下 内 容 : 























export ANT HOME=/usr/lib/apache-ant-1.7.1 
export PATH=$PATH$: SANT _HOME/bin 











输入 以 下 命令 让 配置 生效 : 








source/etc/profile 





同 Windows 下 的 验证 方式 一 样 ， 重 启 终端 ， 执 行 命令 “ant-version”。 如 果 输 出 以 下 内 容 ， 则 说 明 安装 成 功 : 








Apache Ant version 1.7.1 compiled on June 27 2008 





(2) 安装 Eclipse 


同 Windows 环 境 下 的 安装 方式 一 样 ， 直 接 解压 即 可 使 用 。 


1.2 ”获取 Hadoop 源 代码 
































当前 比较 流行 的 Hadoop 源 代码 版 本 有 两 个 : Apache Hadoop 和 Cloudera Distributed Hadoop (CDH) 。Apache Hadoop | 
Yahoo! 、Cloudera、Facebook 等 公司 组 成 的 Hadoop 社 区 共同 研发 的 ， 它 属于 最 原始 的 开源 版 本 。 在 该 版 本 的 基础 上 ， 很 多 公司 
进行 了 封装 和 优化 ， 推 出 了 自己 的 开源 版 本 ， 其 中 ， 最 有 名 的 一 个 是 Cloudera 公 司 发 布 的 CDH 版 本 。 
























































考虑 到 Apache Hadoop 是 最 原始 的 版 本 ， 且 使 用 最 为 广泛 ， 因 而 本 书 选用 了 Apache Hadoop 版 本 为 分 析 对 象 。 自 从 Apache 
Hadoop 发 布 以 来 ， 己 经 陆续 推出 很 多 版 本 (具体 介绍 见 2.1.3 节 ) 。 其 中 ， 最 具有 标志 性 的 版 本 是 1.0.0， 而 该 书 正 是 基于 该 版 本 





















































对 Hadoop MapReduce 进 行 深入 分 析 的 。Hadoop 1.0.0 可 从 httpY/hadoop.apache.org/common/releases.html 或 








http//svn.apache.org/repos/asfhadoop/common/branches/branch-1.01 处 下 载 。 


1.3 ”搭建 Hadoop 源 代码 阅读 环境 


1.3.1 创建 Hadoop 工 程 








本 小 节 介 绍 如 何 创 建 一 个 Hadoop 源 代码 工程 ， 以 方便 阅读 源 代码 。 创 建 一 个 Hadoop 工 程 ， 可 分 两 个 步 又 完成 : 


步 又 1 
Cygwin 安 装 目录 的 home/${USER} 文 件 夹 下 )。 





























步骤 2 新 建 Java 工 程 。 打 








中 “Use default location 前 的 勾 号 ， 然 后 选择 Hadoop 安 装 





钮 ，Hadoop 源 代码 工程 创建 完毕 。 


l } Java - Eclipse - Eclipse 


Edit Source Refactor Navigate Search Project Run Wind 


Alt+Shift+N > 
Open File... 


Ctrl+W 
Ctrl+Shift+W 


Close 
Close All 


Save Ctrl+S 
Save As... 
Save All 


Revert 


Ctrl+Shift+S 


Move... 
Rename... 
Ê) Refresh 


Convert Line Delimiters To 
Print... Ctrl+P 


Switch Workspace 


Alt+Enter 








pni 








到 Eclipse 主 界面 
件 。 























Java 文 














除了 使 














Eclipse， 进 入 Eclipse 可 视 化 界 























mh 
Le 


REBMRRERABQAWAH 








4 i hadoop-1.0.0 





解压 缩 Hadoop 源 代码 。 将 下 载 到 的 Hadoop 源 代码 压缩 包 hadoop-1.0.0.tar.gz 和 解压 到 























Project... 


Package 

Class 

Interface 

Enum 
Annotation 
Source Folder 
Java Working Set 
Folder 

File 

Untitled Text File 
JUnit Test Case 
Task 


Example... 


Other... 


图 


> g src/ant 


> 2 src/benchmarks/gridmix2/src/java 
4 名 src/contrib/capacity-scheduler/src/java 


Ctrl+N 






























































Help = 


| Create a Java Project 





Create a Java project in the workspace or in an external location. 


作 目 录 下 (对 于 Windows 系 统 而 言 ， 为 了 操作 方便 ， 解 压 到 


后 ， 如 图 1-5 所 示 ， 依 次 单 击 '‘File” New’ — Java Project”， 并 在 弹出 的 对 话 框 中 取消 选 
录 的 位 置 。 默 认 情况 下 ， 工 程 名 称 与 Hadoop 安 装 目录 名 称 相同 ， 用 户 可 自行 修改 。 单 击 完成 按 





Project name: fhadcop-1.0.0 











Use default location 








Location: D:\hadoop\hadoop-L.0.0 


JRE 





@ Use an execution environment JRE: |JavaSE-1.6 
Use a project specific JRE: |jre6 


Use default JRE (currently jre6") 


Project layout 
Use project folder as root for sources and class files 


@ Create separate folders for sources and class files 


Working sets 














[Add project to working sets 


Configure JREs... 


Configure default... 





Working sets: 








1-5 新 建 Hadoop 工 程 










4 |B org.apache.hadoop.mapred| 








> [D CapacitySchedulerConfjava 
> D) CapacitySchedulerQueue.java 
四 CapacitySchedulerServietjava 
加 CapacityTaskSchedulerjava 
> [D JobInitializationPoller,java 
> [P] JobQueuesManager.java 
> D) MemoryMatcher.java 
> 名 src/contrib/capacity-scheduler/src/test 
> @ src/contrib/data_join/src/examples 
> 名 src/contrib/data_join/src/java 














1-6 Hadoop T žE 


j 源 代码 压缩 包 导 入 Eclipse 工程 的 方法 外 ， 读 者 可 以 尝试 直接 从 Hadoop SVN 上 导入 Hadoop 源 代码 。 这 些 源 代码 本 身 













展示 《部 分 ) 源 代码 方式 


LU 
WS 
am 








的 ，Hadoop SVN#bhE A: http//svn.apache.org/repos/asfhadoop/common/branches/. 








从 Eclipse 工程 


后 ， 打 开 新 建 的 Hadoop 工 程 ， 可 看 到 整个 工程 的 组 织 代 码 ， 如 图 1-6 所 示 ， 源 代码 按 目 录 组 织 ， 且 每 个 目录 下 以 jar 包 为 单位 显示 











co 


1.3.2 ”Hadoop 源 代码 阅读 技巧 





本 小 节 介 绍 在 Eclipse 下 阅读 Hadoop 源 代码 的 一 些 j 














的 派生 类 或 实现 类 









































在 Eclipse 中 ， 选 中 某 个 基 类 或 接 








ZB, Ail 




















例如 ， 如 图 1-7 所 示 ， 打 





lava- bedasi acne nae 
File Edit Source Refactor Navigate Search 


or 

















Project Run Window Help 


技巧 ， 比 如 如 何 查看 一 个 基 类 有 哪些 派 4 


E 类 、 一 个 方法 被 








srcmapred\ 目 录 下 org.apache.hadoop.mapred 包 中 的 InputFormat.java 文 件 ， 查 看 接 





n-e- HES i *-O-Q-~- 


# Go 


seos- POragn 





(i Package Explorer 2 x 


esl ey =o) 





D FileOutputFormatjava 

加 FileSplitjava 

F HeartbeatResponsejava 

[D HistoryViewerjava 

1D.java 

国 IFilejava 

回 IFileInputStreamjava 

国 IFileOutputStreamjava 

国 IndexCachejava 

[J] InfoMap.java 

[J] InputFormatjava 

因 InputSplitjava 

加 InterTrackerProtocol,java 

D) InvalidFileTypeExceptionjava 
国 InvalidinputException.java 
[D InvalidJobConf€xceptionjava 
A IsolationRunnerjava 
JobACLsManager,java 





a 











图 1-7 在 Eclipse 中 查看 Hadoop 源 代码 


input into <i>lo; 
bytes, of the in 
the input files | 
on the split siz 
<a href="{@docRo4 
mapred.min.split 


<p>Clearly, logi 
applications sin 
application has 
responsibilty to 
view of the logi 


fisee InputSplit 
Osee RecordReade: 
* @see JobClient 
* @see FileInputFo 
bit 
public interface 


e fj 


* Logically spli 


* <p>Each {@link| 





hierarchy of ‘org.apache.hadoop.mapred.InputFormat': 




















其 他 哪些 方法 调 














E 弹 出 的 快捷 菜单 中 选择 “Quick Type Hierarchy*， 可 在 新 窗口 中 看 到 对 应 的 所 有 派生 类 或 实现 类 。 








InputFormat 的 所 有 实现 类 ， 结 果 如 图 1-8 所 示 。 


Undo 
Revert File 
Save 


Open Declaration 
Open Type Hierarchy 
Open Call Hierarchy 
Show in Breadcrumb 
Quick Outline 


Open With 
Show In 


Cut 

Copy 

Copy Qualified Name 
Paste 

Quick Fix 

Source 

Refactor 

Surround With 

Local History 





接口 InputFormat 的 所 有 实现 类 























2. 查 看 函数 的 调用 关系 





在 Eclipse 中 ， 选 中 某 个 方法 名 称 ， 右 击 ， 在 弹出 的 快捷 菜单 中 选择 "Open Call Hierarchy”， 可 在 窗 




















例如 ， 如 图 1-9 所 示 ， 打 








src\mapred\ H 3 | 





F org.apache.hadoop.mapred 4,4 


a DB InputFormat<K, V> - org.apache.hadoop.mapred 


QS ChangelnputFormat - org.apache.hadoop.tools.DistCh 
{& ControlledMapReduceJob - org.apache.hadoop.mapred 
Q? CopyinputFormat - org.apache.hadoop.tools.DistCp 

DH DBInputFormat<T> - org.apache,hadoop.mapred.lib.db 


9 DelegatingInputFormat<K, V> - org.apache.hadoop.mapred.lib 


© EmptyinputFormat<K, V> - org.apache.hadoop.mapred 


@5 Fake IF<K, V> - TestDatamerge 


@5 Fake IF<K V> - org.apache.hadoop.mapred,join.TestDatamerge 


@5 FakelF - org.apache.hadoop.mapred.TestMapCollection 


4 H* FileInputFormat<K, V> - org.apache.hadoop.mapred 
a ^" CombinefileInputFormat<K, V> - org.apache.hadoop.mapred.lib 
@ _DummyinputFormat - org.apache.hadoop.mapred lib. TestCombinefilelnputFormat 
9% DummyfileInputFormat - org.apache.hadoop.mapred.TestFileInputFormatPathFilter 


4 © KeyValueTextinputFormat - org.apache.hadoop.mapred 





图 1-8 ”Eclipse 列 出 接口 InputFormat 的 所 有 实现 类 
































“Call Hierarchy H Æ FA V} 






































P 的 JobTrackerjava 文 件 ， 查 看 调 

















方法 iniyob 的 所 有 函数 ， 结 果 如 图 














Alt+Shift+W > 


Ctrl+X 
Ctrl+C 


Ctrl+V 
Ctrl+1 


Alt+Shift+S > 
Alt+Shift+T > 
Alt+Shift+Z > 


该 方法 的 函数 。 


1-10 所 示 。 











1 Package Explorer 52 ^ 





FEE RE 





四 JobProfilejava 

È JobQueueCliontjava 

J) JobQueuelnto.java 

D JobQueuelobInProgressListenerjava 
国 JobQueueTaskScheduler.java 
国 JobStatus.java 
JobStatusChangeEventjava 

P) JobSubmissionProtocol java 
DB) JobTrackerinstrumentationjava 
Bi) JobTrackerMetricsSource java 
四 JobTrackerMXBean,java 

国 JobTrackerStatistics java 

A) JSPUtil java 

因 JumContextjava 
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IN 


ify ba i e a A a 峰 Gv- Gece: E E A 















1-9 在 Eclipse 中 查看 Hadoop 源 代码 中 所 有 调 









































Undo Ctrl+Z 
Revert File 
Save Ctrl+S 
Open Declaration F3 
“Deleg Open Type Hierarchy 
} 
String user 
return secre Show in Breadcrumb Alt+Shift+B 
} Quick Outline ctr+O 
= public void I Quick Type Hierarchy Ctd+T 
if (null == R 
106- nfo( | E 
return; Show In Alt+Shift+W > 
} Cut Ctd+X 
eyi Ctri+C 
Jobstatus Sal m 
L0G. info(" Copy Qualified Name 
job.initTa Paste Ctnd+V 
j4 Inform 
74 oe 3 Quick Fix Ctr+1 
1e Greva. | Source Alt Shift+S + 
JobTracker.java 中 initJob 方 法 的 函数 





vvuvvy 


3. 快 速 查找 类 对 象 的 相关 信息 


FR PVR, PARR, Ail 





不 做 详细 介绍 ， 读 者 可 自行 尝试 。 





Problems | @ Javadoc | 区 Declaration X 


Members calling 'initobUobinprogress)' - in workspace 
i initlobUobInProgress) : void - org.apache.hadoop.mapred.JobTracker, 








checkAndInit0 : void - org.apache.hadoop,mapredJobTracker.RecoveryManager.JobRecoveryListener 

initializeJobUobID) : void - org.apache.hadoop.mapred.MiniMRCluster 

initializeJobsQ) : void - org.apache.hadoop.mapredJobInitializationPollerJoblnitializationThread 

run0 : void - org.apache.hadoop.mapred.EagerTaskinitializationListener.Inivob 

run0 : void - org.apache.hadoop.mapred.FairScheduler.Jobinitializer.Initob 

testiobRecoveryWithEmptyHistory(MiniDFSCluster, MiniMRCluster) ; void - org.apache.hadoop.mapred,.TestiobTrackerRestart (2 matches) 

















PR] 














1-10 ”Eclipse 列 出 所 有 调 





jinitJob 方 法 的 函数 


co 











Ei 
A 
2 
2 
= 
a 
ce 





中 选择 "Open Declaration”， 可 跳 转 到 类 定义 ; 选择 "Quick Outline”， 可 查看 类 所 有 的 成 员 变 量 和 成 员 方 法 。 具 体 细节 本 





1.4 ”Hadoop 源 代码 组 


个 模块 ， 即 基础 


本 了 


织 结 


一 人 一 口 


构 



























































〇 O 尽 可 能 模块 化 ， 即 每 个 重要 模块 扣 


Dconf 配置 文件 所 在 目录 。Hadoop 


直接 解压 Hadoop 压 缩 包 后 ， 可 看 到 图 1-11 所 示 的 目 
几 个 目录 的 作用 : 


Osre: Hadoop 源 代码 所 在 的 目录 。 最 核心 的 代码 所 在 子 目 
公共 库 、HDFS 实 现 和 MapReduce 实 











的 配置 文件 上 





















































〇 动静 分 离 ， 即 将 可 动态 加 载 的 配置 选项 录 








开始 ， 这 些 配置 选项 被 录 
重要 的 配置 文 伯 














架 MapReduce 的 配置 选项 。 





相关 的 配置 选项 被 放 在 配置 文件 mapred-site.xml 中 ， 








有 自己 的 配置 文件 ， 





这 上 





使 得 维护 以 及 管理 变 得 简单 。 


| 离 出 来 ， 组 成 独立 配置 文件 。 


























| 离 放 到 独立 配置 文 伯 





该 文件 是 不 可 以 





J 


O 





Fmapred-queue-acjk.xml 中 , 


FE 有 core-site.xnl、 hd 人 -site.xml 和 mapred-site.xml， 分 别 设置 了 基础 











E 较 多 ， 其 设计 原则 可 概括 为 如 下 两 点 。 

















世 





E 
[ 载 的 ， 每 次 修改 后 必须 重 
该 文件 可 以 通过 Hadoop 命 令 





态 力 











kan, Hadoop 1.0.0 版 本 之 前 ， 作 业 队 列 权限 管理 














录 结 构 ， 其 中 ， 比 较 重 要 的 目录 有 src、conf lb, bn. FAH Aix 
录 分 别 是 core、hd 和 mapred， 它 们 分 别 实现 了 Hadoop 最 重要 的 三 





























ic 


启 MapReduce。 但 从 1.0.0 版 
行动 态 加 载 。conf 介 录 下 最 


系统 HDFS 和 分 布 式 计算 框 




















公共 库 core、 分 布 式 文 从 











Olib: Hadoop 运 行 时 依赖 的 三 方 库 ， 包 括 编 译 好 的 jar 包 以 及 其 他 语言 生成 的 动态 库 。Hadoop 启 动 或 者 用 户 提交 作业 时 ， 会 
自动 加 载 这 些 库 。 























Hadoop 集 群 














Ohadoop: 最 基本 且 功 能 最 完备 























关 的 脚本 。 这 上 


的 管理 脚本 ， 其 























F 


介绍 几 个 常用 的 脚本 。 


他 大 部 分 脚本 都 会 调用 该 脚本 。 


Ostart-all sh/stop-allsh: 启动 /停止 所 有 节点 上 的 HDFS 和 MapReduce 相 关 服 务 。 


Ostart-mapred.sh/stop-mapred.sh: 单独 启动 /停止 MapReduce 相 关 服 务 。 


Ostart-df8.sh/stop-df.sh: 单独 启动 /停止 HDFS 相 关 服 务 。 


Hzsdccp 安 装 目录 


HADOOP HOME 


Hadccp 小 代码 


znt Ante PEAK (US 

conf 存放 各 科 配 置 文件 = Map Reduce INER i arid 
eee Ger: eee 

hin 存放 各 御 Hadcc pet A 


hadccp CCjar j Hadccp 代 码 编译 后 的 jar 似 


功能 扩展 各 如 其 他 Hadaap 庶 度 器 ，Hadaap Streaming 等 
基础 代码 库 


文档 


此 MapReduce 作 业 示 例 程序 , 包括 Java、C++ 和 Python 三 科 语 言 实现 


本 和 





重点 介绍 MapReduce 的 实现 原理 


构 叫 如 图 1-12 所 示 。 


总 体 上 看 ，Hadoop MapReduce 分 为 两 部 分 : 一 部 分 是 org.apache.hadoop.mapred.*， 这 里 面 主要 包含 | 


a a 


4) 


HDFS 实 现代 码 


| 
| 








i narra | MapReduce’): 现代 码 
test 


RAF 


图 1-11 Hadoop 安 装 目录 结构 


Weh 界 面相 闫 的 sp 代码 














4 中 src/mapred 


> §8 org.apache.hadoop.filecache 

> G8 org.apache.hadoop.mapred 

> §8 org.apache.hadoop.mapredjobcontrol 

> G8 org.apache.hadoop.mapred.join 

> §8 org.apache.hadoop.mapred.lib 

> §8 org.apache.hadoop.mapred.lib.aggregate 
> §8 org.apache.hadoop.mapred.lib.db 

> §8 org.apache.hadoop.mapred.pipes 

> {8 org.apache.hadoop.mapred.tools 





> GB org.apache.hadoop.mapreduce 

> 48 org.apache.hadoop.mapreduce.lib.input 

> 出 org.apache.hadoop.mapreduce.lib.map 

> $ org.apache.hadoop.mapreduce.lib.output 
> {$ org.apache.hadoop.mapreduce.lib.partition 
> $ org.apache.hadoop.mapreduce.lib.reduce 
> 出 org.apache.hadoop.mapreduce.security 


> 出 org.apache.hadoop.mapreduce.security.token 


> £8 org.apache.hadoop.mapreduce.security.token.delegation 
> $ org.apache.hadoop.mapreduce.server.jobtracker 

> d org.apache.hadoop.mapreduce.server.tasktracker 

> ,出 org.apache.hadoop.mapreduce.server.tasktracker.userlogs 





> $8 org.apache.hadoop.mapreduce.split 


图 1-12 Hadoop MapReduce 源 代码 组 织 结构 


























本 地 库 ， 主 要 是 压缩 纺 解 码 器 


针对 pm 或 者 deh 发 行 版 的 管理 工具 


Hadoop 工 具 ， 比 如 日 去 分 析 工 具 等 

















E, Fa Hadoop MapReduce 源 代码 组 织 结构 进行 介绍 。Hadoop MapReduce 源 代码 组 织 结 


的 对 外 编程 接口 以 及 


MapReduce 各 个 服务 〈JobTracker 以 及 TaskTracker) 的 实现 ;， 另 一 部 分 是 orgapache.hadoop.mapreduce.*， 主 要 内 容 涉 及 新 版 本 的 对 











外 编程 接口 以 及 一 些 新 特性 〈 比 如 MapReduce 安 全 ) 。 




















1.MapReduce 编 程 模 型 相关 














Qorg, apache.hadoop.nmmapred.lib.*: 这 一 系列 Java 包 提供 了 各 种 可 直接 在 应 用 程序 中 使 用 的 InputFormat、Mapper、Partitioner、 























Reducer 和 OuputFormat， 以 减少 用 户 编写 MapReduce 程 序 的 工作 量 。 

















Qorg, apache.hadoop.mapred.jobcontrol: 该 Java 包 人 允许 用 户 管理 具有 相互 依赖 关系 的 作业 (DAG 作业 〉。 















































可 以 只 使 用 Map Task 实 现 join 算 法 ， 避 人 免 re-partition、sort、shuffing 等 开销 。 

















Dorg apache.hadoop.mapred.pipes: 该 Java 包 人 允许 用 户 用 C/C++ 编写 MapReduce 作 业 。 




















OuputFormat。 
2.MapReduce 计 算 框 架 相关 


Dorg apache.hadoop.mapred: Hadoop MapReduce 最 核心 的 实现 代码 ， 包 括 各 个 服务 的 具体 实现 。 























应 用 程序 中 需要 的 文件 分 发 到 各 个 节点 上 。 









































口 org apache.hadoop.mapred.join: 该 Java 包 实现 了 map-side join 算法 中 。 该 算法 要 求 数据 已 经 按照 key 排 好 序 ， 且 





口 org. apache.hadoop.mapreduce: 该 Java 包 定义 了 一 套 新 版 本 的 编程 接口 ， 这 套 接口 比 旧 版 接口 封装 性 更 好 。 


口 org. apache.hadoop.mapreduce.*: 这 一 系列 Java 包 根据 新 版 接口 实现 了 各 种 InputFormat、Mapper、Partitioner、Reducer 和 


分 好 片 ， 这 样 


T 


























DQ org. apache.hadoop.mapred.filecache: Hadoop DistributedCache 实 现 。DistributedCache 是 Hadoop 提 供 的 数据 分 发 工具 ， 可 将 用 




















口 org, apache.hadoop.mapred.tools: 管理 控制 Hadoop MapReduce， 当 前 功能 仅 包括 允许 用 户 动态 更 新 服务 级 别 的 授权 策略 和 





ACL 访问 权限 控制 ) 属性 。 





口 org. apache.hadoop.mapreduce.split: 该 Java 包 的 主要 功能 是 根据 作业 的 InputFormat 生 成 相应 的 输入 split。 





























Qorg, apache.hadoop.mapreduce.server.tasktracker.*: TaskTracker 的 一 些 辅助 类 。 








3.MapReduce 安 全 机 制 相 关 























这 里 只 涉及 org.apache.hadoop.mapreduce.security.*。 这 一 系列 Java 包 实现 了 MapReduce 安 全 机 制 。 























[1] 不 同 版 本 Hadoop 的 源 代码 结构 稍 有 差距 ， 本 书 的 分 析 是 基于 Hadoop 1.0.0 版 本 的 。 











[2] Join 算 法 是 将 两 个 表 或 者 文件 按照 某 个 key 值 合并 起 来 ， 在 Hadoop 中 ， 可 以 在 Map 或 者 Reduce 端 进行 合并 。 
































并 ， 则 需要 进行 re-partition、sort、shufling 等 操作 ， 开 销 很 大 。 























Dorg, apache.hadoop.mapreduce.server.jobtracker: 该 Java 包 维护 了 JobTracker 可 看 到 的 TaskTracker 状 态 信息 和 资源 使 用 情况 。 














若 在 Reduce 端 进 





TA 


1.5 Hadoop 初 体验 











一 般 而 言 ， 我 们 想 要 深入 学 习 一 个 新 的 系统 时 ， 首 先 要 尝试 使 用 该 系统 ， 了 解 系统 对 外 提供 的 功能 ， 然 后 通过 某 个 功能 逐步 











se 
RARS 
长 





























现 细节 。 本 节 将 介绍 如 何在 伪 分 布 式 工 作 模 式 [下 使 用 Hadoop， 包 括 启动 Hadoop、 访 问 HDFS 以 及 向 MapReduce 提 交 作 


实 
业 等 最 基本 的 操作 。 本 节 只 是 有 代表 性 地 介绍 Hadoop 的 一 些 基 本 使 用 方法 ， 使 读者 对 Hadoop 有 一 个 初步 认识 ， 并 引导 读者 逐步 











进行 更 全 面 的 学 习 。 














1.5.1 启动 Hadoop 


步骤 1 修改 Hadoop 配 置 文件 。 在 con 人 目 录 下 ， 修 改 mapred-site.xml、core-site.xml 和 hdf-site.xml 三 个 文 但 








</configuration> Z [AJ Ys HLA BA 


口 mapred-site. xml: 





F, 7£<configuration> 与 





<property> 
<name>mapred.job.tracker</name> 
<value>localhost: 9001</value> 
</property> 





Ocore-site.xml: 





<property> 
<name>fs.default.name</name> 
<value>hdfs: //localhost: 9000</value> 
</property> 





DQ hdfs-site.xml: 





<property> 
<name>dfs.replication</name> 
<value>1</value> 
</property> 

<property> 
<name>dfs.permissions</name> 
<value>false</value> 
</property> 








如 果 是 Windows 环 境 ， 还 需要 在 hadoop-env.xml 中 添加 以 下 配置 : 








export JAVA HOME=D:/hadoop/Java/jdk1l.6.0 27 














步骤 2 设置 免 密 码 登 录 。 前 面 提 到 Hadoop 启 动 启动 /停止 脚本 时 需要 通过 SSH 发 送 命 令 启动 相关 守护 进程 ， 























动 /停止 Hadoop 输 入 密码 进行 验证 ， 需 设置 免 密码 登录 ， 设 置 步骤 如 下 。 


D 打开 命令 行 终端 (Windows 下 为 Cygwin 终 端 ，Linux 下 为 Shel 终 端 ， 下 同 ) ， 输 入 以 下 命令 : 











为 了 避免 每 次 启 





ssh-keygen-t rsa 








执行 上 述 命令 后 ， 将 会 在 “一 /ssh/" 目 录 下 生成 公 钥 文件 和 drsa.pub 和 私 钥 文件 过 Tsa。 

















2) 将 公 钥 文件 id_rsa.pub 中 的 内 容 复 制 到 相同 目录 下 的 authorized keys 文 件 





| 








cd~/.ssh/ 
cat id_rsa.pub>>authorized_keys 





步骤 3 启动 Hadoop。 在 Hadoop 安 装 目录 中 ， 按 以 下 两 步 操作 启动 Hadoop。 


1) 格式 化 HDFS: 





bin/hadoop namenode-format 





2) 启动 Hadoop: 





bin/start-all.sh 





通过 以 下 URL 可 查看 MapReduce 是 否 启动 成 功 : 





http://localhost: 50030/ 





通过 以 下 URL 可 查看 HDFS 是 否 启 动 成 功 : 





http://localhost: 50070/ 








经 过 以 上 两 步 操 作 ，Hadoop 成 功 启动 ， 接 下 来 可 以 通过 Hadoop Shel 或 者 Eclipse 插件 访问 HDFS 和 提交 MapReduce 作 业 。 下 面 
两 小 节 分 别 介 绍 Hadoop Shel 和 Eclipse 插件 的 使 用 方法 。 























[1] 单机 环境 中 ，Hadoop 有 两 种 工作 模式 : 本 地 模式 和 伪 分 布 式 模 式 。 其 中 ， 本 地 模式 完全 运行 在 本 地 ， 不 会 加 载 任 何 
MapReduce 服 务 ， 因 而 不 会 涉及 MapReduce 最 核心 的 代码 实现 ， 伪 分 布 式 模式 即 为 “ 单 点 集群 ”在 该 模式 下 ， 所 有 的 守护 进程 均 
会 运行 在 单个 节点 上 ， 因 而 本 节选 用 该 工作 模式 。 


















































1.5.2 Hadoop Shell 介 绍 




















在 1.4 节 中 曾 提 到 ，bin 目 录 下 的 Hadoop 脚 本 是 最 基础 的 集群 管理 脚本 ,用户 可 以 通过 该 脚本 完成 各 种 功能 ， 如 HDFS 文 件 管 








EE 等。 该 脚本 的 使 用 方法 为 : 














理 、MapReduce 作 业 管 到 








hadoop[--config confdir]COMMAND 


其 中 ，--config 用 于 设置 Hadoop 配 置 文件 目录 ， 默 认 目 录 为 SHADOOP HOME}conf。 而 COMMAND 是 
的 有 HDFS 管 理 命令 全 、 作 业 管 理 命令 job 和 作业 提交 命令 jar 等 。 它 们 的 使 用 方法 如 下 : 























LR SES aS > H 



















































































(1) HDFS# #2 474 BANE Le EE at A job 





























bin/hadoop command[genericOptions] [commandOptions] 








其 中 ，command 可 以 是 人 或 者 job, genericOptions 是 一 些 通用 选项 ，commandOptions 是 人 氏 或 者 job 附加 的 命令 选项 。 看 下 面 两 个 例 


本 





口 在 HDFS 上 创建 一 个 目录 /test: 





bin/hadoop fs-mkdir/test 





口 显 示 Hadoop 上 正在 运行 的 所 有 作业 : 








bin/hadoop job-list 





(2) 作业 提交 命令 jar 





hadoop jar<jar>[mainClass]args.. 


其 中 ， 芭 jar> 表 示 jar 包 名 ; mainClass 表 示 main class 名 称 ， 可 以 不 必 输 入 而 由 jar 命 令 自 动 搜索 ，args 是 main class 输 入 参数 。 举 例 





如 下 : 
bin/hadoop jar hadoop-examples-1.0.0.jar wordcount/test/input/test/ouput 


PS aT A SCE EE BES Ed 























其 中 ，wordcount 是 hadoop-examples-1.0.0.jar 中 一 个 作业 名 称 。 顾 名 思 义 ， 该 作业 月 
ABR: 输入 数据 目录 (/test/input) 和 输出 数据 目录 (/test/output》。 











数 ， 它 有 两 个 输 





官方 设计 文档 。 











至 于 其 他 更 多 命令 ， 读 者 可 自行 查阅 Hadoop 








1.5.3. Hadoop Eclipse 插件 介绍 























Hadoop 提 供 了 一 个 Eclipse 插件 以 方便 用 户 在 Eclipse 集成 开发 环境 中 使 用 Hadoop， 如 管理 HDFS 上 的 文件 、 提 交 作 业 、 调 试 MapReduce 程 序 等 。 本 小 节 


















































将 介绍 如 何 使 用 该 插件 访问 HDFS、 运 行 MapReduce 作 业 和 跟踪 MapReduce 作 业 运 行 过 程 。 








1. 编 译 生成 Eclipse 插 件 

















用 户 需要 自己 生成 Eclipse 插 件 。Hadoop-1.0.0 生 成 的 jar 包 不 能 直接 使 用 ， 需 要 进行 部 分 修改 ， 具 体 参考 附录 A 中 的 问题 2， 其 代码 位 于 Hadoop 安 装 目 
录 的 src/contrib/eclipse-plugin 下， 在 该 目录 下 ， 输 入 以 下 命令 生成 Eclipse 插 件 : 

































































ant-Declipse.home=/home/dong/eclipse-Dversion=1.0.0 















































其 中 ，eclipse.home 用 来 指定 Eclipse 安 装 目录 ，version 是 Hadoop 版 本 号 。${HADOOP_HOME}/build/contrib 目 录 下 生成 的 hadoop-eclipse-plugin-1.0.0.jar 文 
件 即 为 Eclipse 插件 。 














2. 配 置 Eclipse 插 件 

















将 生成 的 Eclipse 插 件 hadoop-eclipse-plugin-1.0.0.jar 复 制 到 Eclipse 安 装 目 录 的 plugins 文 件 夹 下 ， 然 后 重启 Eclipse。 




































































进入 Eclipse 后 ， 按 照 以 下 步骤 进行 设置 : 在 菜单 栏 中 依次 单 击 “Window 一 "Show View 一 “Other..….” 在 对 话 框 中 依次 单 击 “MapReduce 
Tools' 一 “Map/Reduce Locations”， 会 弹出 图 1-13a 所 示 的 对 话 框 ， 按 图 中 提示 填写 内 容 。 
































经 上 述 步骤 后 ， 回 到 主 界面 ， 如 图 1-13b 所 示 ， 可 在 “Project Explore" 视 图 中 查看 分 布 式 文件 系统 的 内 容 ， 说 明 Eclipse 插 件 安装 成 功 。 


























Define Hadoop location 


Define the location of a Hadoop infrastructure for running MapReduce 
applications. 


General | Advanced parameters $ Java - Eclipse 一 























Location name: hadoop test File Edit Navigate Search | Project) Run Window Help 








Map/Reduce Master DFS Master 基本 | 1 & i wer O~ Q ~ Gy  @e@ 


Host yy maea (H8 Package Explorer is see 


Host: | localhost 


4 f hadoop test 















































User name: trss Í & QM 
SOCKS e ror 
KS PION 4 © hadoop-trss (1) 
F] Enable SOCKS proxy 4 © mapred (1) 
Host: [host | 4 & system (1) 
ER | 1080 B jobtracker.info (4.0 b, r1) 
a) b) 








图 1-13 配置 Hadoop Eclipse 插件 
a) 配置 MapReduce 和 HDFS 的 主机 名 和 端口 号 b) 显示 HDFS 中 的 文件 列表 





























3. 运 行 MapReduce 作 业 























前 面 提 到 ， 在 伪 分 布 式 环境 下 ， 单 个 节点 上 会 同时 运行 多 种 Hadoop 服 务 。 为 了 跟踪 这 些 服 务 的 运行 轨迹 ,我们 采用 了 以 下 方法 向 Hadoop 提 交 一 
个 MapReduce 作 业 ， 通 过 跟踪 该 作业 的 运行 轨迹 来 分 析 Hadoop 的 内 部 实现 原理 。 












































该 方法 可 通过 以 下 三 个 步 又 完成 : 

















HH 














步骤 1 新 建 一 个 MapReduce 工 程 。 在 菜单 栏 中 ， 依 次 单 击 "New 一 Other... ”MapReduce Project”， 会 弹出 图 1-14 所 示 的 对 话 框 。 在 该 对 话 框 中 填写 
项 目 名 称 ， 并 配置 Hadoop 安 装 目 录 ， 此 处 可 直接 选择 前 面 已 经 建 好 的 Java 工 程 'hadoop-1.0.0”。 






























































步骤 2 
[ 程 中 。 





步 又 3 


$ New MapReduce Project Wizard 


MapReduce Project 


@ Invalid Hadoop Runtime specified; please click ‘Configure Hadoop 
install directory’ or fill in library location input field 


Project name: [MapReduceJobs 








| Use default location 











| | Browse... 





Location: (EAUsers\rssworkspace\ MapReduce) obs 





Hadoop MapReduce Library Installation Path 
f> 


Conf qure Hadoop install directory..; 


@ Use default Hadoop {currently not set) 
| | Browse... | 


© Specify Hadoop library location | 











图 1-14 在 Eclipse 中 创建 MapReduce 工 程 















































准备 MapReduce 作 业 。 可 直接 将 Hadoop 源 代码 中 src\examples\or&apache\hadoop\examples 


运行 作业 。 














D 准备 数据 。 如 图 1-15 所 示 ， 在 HDFS 上 创建 目录 /test/input， 并 上 传 几 个 文本 文件 到 该 目录 中 。 



































2) 配置 输入 /输出 路 径 。 如 图 1-16 所 示 ， 在 WordCount.java 中 右 击 ， 在 弹出 的 快捷 菜单 中 依次 单 击 “Run As 一 "Run Configurations. ..... ， 
所 示 的 对 话 框 。 双 击 “Java Applications 选项， 在 新 建 的 对 话 框 中 输入 作业 的 输入 /条 出 路 径 


E DFS Locations 
4 f hadoop test 
*@ 2) 
4 © test (1) 
4 je inp i 





i3 Download from DFS.. 


C3 Create new directory... 


4 tı 1 
& tmp a Upload files to DFS... 


> & had 
> 酌 hadoop-1.0.0 
> E! MapReduceJobs @ Refresh 


25 Upload directory to DFS... 


X Delete 























图 1-15 使 用 Eclipse 插件 上 传 文件 到 HDFS 





















































中 间 用 空格 分 隔 ) ， 并 单 击 “Apply 按钮 保存 。 














Tan 




















现 图 


录 下 的 WordCountjava 复 制 到 新 建 的 MapReduceJobs 


1-17 








package org.apache.hadoop.| < Undo 


i Revert File 
® import java.io.IOException & 
ave 


public class WordCount {| 


Open Declaration 
© public static class Toke Open Type Hierarchy 
extends Mapper<Obje Open Call Hierarchy Ctrl+Alt+H 
Show in Breadcrumb Alt+Shift+B 
Quick Outline Ctrl+O 
Quick Type Hierarchy Ctrl+T 
public void map (Object, Show In Alt+Shift+W > 
) thra 
StringTokenizer itr Cut Ctrl+X 
while (itr.hasMoreTo Copy Ctrl+C 


d.set (itr. tT s 
Te re oe Copy Qualified Name 
context .write (word 
Paste Ctrl+V 








private final static I 
private Text word = ne 


Quick Fix Ctrl+1 
Source Alt+Shift+S > 
© public static class ai Refactor Alt+Shift+T > 


extends Reducer<Te ss 
Local History 








Í | Ref 
fa Problems | @ Javadoc | {®, Declaratio PIETER 








Declarations 
Location 


By EEF [E Add to Snippets... 


[Rms avn Application Attstihtx) 


>| Ñ 2 Run on Hadoop 





Run Configurations... 











图 1-16 在 Eclipse 中 配置 作业 的 输入 /输出 路 径 (1) 





一 一 一 
= Run Configuration 


Create, manage. and run configurations 


Run a Java application 











>, 
£ x | SE: Name: WordCount 


npa mieca © Mainfor arguments BE JRE) ĉ¢ Classpath | By Source | ”2 


Java Applet Program arguments: 


E Java Application 
/test/input /test/ouput 
D WordCount P P 


Ju JUnit 
Jy Task Context Test 




















VM arguments: 





Working directory: 
@ Default: | ${workspace_loc:hadoop-1.0.0} 











© Other: | 








| Workspace... | | File System... | | Variables... | 


























Filter matched 5 of 5 items [Ace] 
® 








图 1-17 在 Eclipse 中 配置 作业 的 输入 /输出 路 径 (2) 











3) 运行 作业 。 在 WordCount.java 中 右 击 ， 在 弹出 的 快捷 菜单 中 依次 单 击 “Run As”—“Run on Hadoop”， 会 出 现 如 图 1-18 所 示 的 对 话 框 。 按 图 中 的 提示 选 
择 后 ， 单 击 “Finish 按钮 ， 作 业 开始 运行 。 



































此 外 ， 有 兴趣 的 读者 可 以 在 MapReduce 作 业 中 设置 断 点 ， 对 作业 进行 断 点 调试 。 








Select Hadoop location 


Select a Hadoop location to run on. 





Select a Hadoop Server to run on. 
© Define a new Hadoop server location 


@ Choose an existing server from the list below 





Master host name 
localhost 

















图 1-18 在 Eclipse 中 运行 作业 





1.6 编译 及 调试 Hadoop 源 代码 








读者 在 阅读 源 代 码 的 过 程 中 ， 可 能 需要 修改 部 分 源 代码 或 者 使 用 调试 工具 以 便 跟 踪 某 些 变量 值 的 变化 过 程 ， 此 时 要 用 到 
Hadoop 源 代码 编译 和 调试 方法 。 本 节 将 介绍 Hadoop 在 伪 分 布 式 模式 下 的 编译 和 调试 方法 ， 其 中 ， 调 试 方法 主要 介绍 使 用 Eclipse 远 
程 调试 和 打印 调试 日 志 两 种 。 

















1.6.1 编译 Hadoop 源 代码 


在 Windows 或 Linux 环 境 下 ， 打 开 命令 行 终端 ， 转 到 Hadoop 安 装 目录 下 并 输入 以 下 命令 : 








ant-—Dversion=1.0.0{target} 








其 中 ，f{target} 值 如 表 1-2 所 示 ， 不 同 的 target 可 对 应 生成 不 同 的 jar 包 ， 如 : 





ant-Dversion=1.0.0 examples 








可 生成 hadoop-examples-1.0.0.jar， 产 生 的 jar 包 位 于 Hadoop 安 装 目录 的 build 文 件 夹 下 。 





表 1-2 编译 target 与 对 应 生成 的 jar 包 


target jar 包 
jar hadoop-core-1.0.0.jar 
examples hadoop-examples-1.0.0.jar 
tools-jar hadoop-tools-1.0.0.jar 
jar-test hadoop-test-1.0.0.jar 


ant-tasks hadoop-ant-1.0.0.jar 


1.6.2 ”调试 Hadoop 源 代码 





本 小 节 介 绍 两 种 调试 方式 ， 利用 Eclipse 远程 调试 和 打印 
Hadoop。 本 小 节 主 要 介绍 伪 分 布 式 工作 模式 下 的 Hadoop 调 








2H 








试 日 志 。 这 两 种 方式 均 可 以 调试 伪 分 布 式 工 作 模式 和 完全 分 布 式 工作 模式 下 的 
试 方法 。 
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1. 利 用 Eclipse 进行 远程 调试 






































下 面 以 调试 JobTracker 为 例 ， 介 绍 利用 Eclipse 进行 远程 调试 的 基本 方法 。 调 试 过 程 可 分 三 步 进行 : 











步骤 1 调试 模式 下 启动 Hadoop。 


在 Hadoop 安 装 目录 下 运行 内 容 如 下 的 Shel 脚 本 : 





export HADOOP_JOBTRACKER_OPTS="-Xdebug-Xrunjdwp: transport=dt_socket, address=878 8, server=y, suspend=y" 
bin/start-all.sh 








如 果 脚 本 运行 成 功 ， 则 可 以 看 到 Shel 命 令 行 终端 显示 如 下 信息 : 





Listening for transport dt_socket at address: 8788 














此 时 表明 JobTracker 处 于 监听 状态 。JobTracker 将 一 直 处 于 监听 状态 ， 直 到 收 到 debug 确 认 信息 。 




















Na 


PER2 ”设置 断 点 。 





























在 前 面 新 建 的 Java 工 程 'hadoop-1.0.0” 中 ， 找 到 JobTracker 相 关 代码 ， 并 在 感 兴趣 的 地 方 设置 一 些 断 点 。 

















Na 


又 3 ”在 Eclipse 中 调试 Hadoop 程 序 。 


























在 Eclipse 的 菜单 栏 中 ， 依 次 单 击 ' 了 um 一 “Debug Configurations” —Remote Java Applications”， 打 开 图 1-19 所 示 的 对 话 框 ， 按 图 中 的 提示 填写 名 称 、 
JobTracker 所 在 的 host 以 及 监听 端口 ， 并 选择 Hadoop 源 代码 工程 ， 进 入 图 1-20 所 示 的 调试 模式 。 






























































= Debug Configurations mn? come 
Create, manage. and run configurations 
Attach to a Java virtual machine accepting debug connections 
f 
CBX | IE .By Name:] JobTracker_Debugger 
[type filter text | [ Connect, sy Source | i Common | | 
Java Applet Project: 
Selle Bio Eeeoea 
Ju JUnit badoan 
T, Remote Java Applicati Connection Type: 
T, JobTracker Debug (Standard (Socket Attach) z) 





Ju Task Context Test 
Connection Properties: 


Host: Jlocalhost 


Port 


F] Allow termination of remote VM 
































a] it 上 


Filter matched 8 of 12 items | Apply | [ Revet | 






































图 1-19 在 Eclipse 中 配置 远程 调试 器 











性 Debug - hadoop-1.0.0/sr</n o d acker 
[Fie Eat Source Refactor Navigate Search Project Run Window Help 















































throws IOException, InterruptedException { 
this.queueManager = qm; 


a queueManager : QueueManager 
a" JobTracker(JobConf) 


i C-RBS: *#-OvQ-i@Or-i PAVE HBr Vero ty [BE Debug |A Mar” 
| ` ~ 
E Debug 52° I Sie i ew | 2 D.R = | S| @ Y = G)\{e0- Variables x Po Breakpoints | a E e A T | 
E WordCount [Java Application] * || Name Value | 
| E JobTracker Debugger [Remote Java Application] | e this JobTracker (id=41) | 
Š OpenJDK 64-Bit Server VM[10.1.1.97:8788] @ wa JobConf (id=28) 
a® Thread [main] (Suspended (breakpoint at line 2205 in JobTracker)) O identifier "201205142011" (id=42) 
= JobTracker.<init>UobConf, String, Clock, QueueManager) line: : @ dock Clock (id=46) 
= JobTracker,<init>UJobConf, String, Clock) line: 2192 © qm QueueManager (id=48) 
= JobTracker.<init>VobConf, String) line: 2186 @ addr InetSocketAddress (id=50) 
| = JobTracker.startTrackerJobConf, String) line: 300 =: | RR HW t 
一 
| PE | < Š 
Hi) JobTrackerjava 22 N dN JobConfjava | = 2 (Be Outline £3) vlitjawe wv ro 
© JobTracker (final JobConf conf, String identifier, Clock clock, QueueM a = à memSizeForReduceSlotOnJT : long 














this.clock = clock; =] c 

// Set ports, start RPC servers, setup security policy etc. ms «Rea GIH an QueueManager) 

InetSocketAddress addr = getAddress(conf); a a“ JobTracker(JobConf, Clock) 

this.localMachine = addr.getHostName(); {as cf JT_USER_NAME : String 

this.port = addr.getPort(); oF JT_KEYTAB FILE : String 

// find the owner of the process a at JobTracker(JobConf, String) 

n RLA 一 a" JobTracker(obConf, String, Clock) 

SecurityUtil.login(conf, JT KEYTAB FILE, JT USER NAME, localMachine Š 4 |ia ° JobTracker(JobConf, String, Clock, Queue 
b Q new PrivilegedExceptionAction<Boole: 

long secretKeyInterval = = b Q new PrivilegedExceptionAction<FileSys 

conf.getLong (DELEGATION KEY UPDATE INTERVAL KEY, 2 b Q new PrivilegedExceptionAction<FileSys = 








4 m 上 4 m + 

















图 1-20 Eclipse 中 显示 的 Hadoop 调 试 窗口 





























调试 过 程 中 ，JobTracker 输 出 的 信息 被 存储 到 日 志文 件 夹 下 的 hadoop-XXX-jobtracker-localhost.log 文 件 〈XXX 为 当前 用 户 名 ) 中 ， 可 通过 以 下 命令 
查看 调试 过 程 中 打印 的 日 志 : 




















tail-f logs/hadoop-XXX-jobtracker-localhost.log 





2. 打 印 Hadoop 调 试 日 志 





Hadoop 使 用 了 Apache log4j!'! 作 为 基础 日 志 库 。 该 日 志 库 将 日 志 分 为 5 个 级 别 ， 分 别 为 DEBUG、JINFO、WARN、ERROR 和 FATAL。 这 5 个 级 别 对 
应 的 日 志 信 息 重要 程度 不 同 ， 它 们 的 重要 程度 由 低 到 高 依次 为 DEBUG<INFO 二 WARN 二 ERROR<FATAL。 日 志 输 出 规则 为 ， 只 输出 级 别 不 低 于 设 
定 级 别 的 日 志 信 息 。 比 如， 级 别 设 定 为 INFO， 则 INFO、WARN、ERROR 和 FATAI 级 别 的 日 志 信息 都 会 被 输出 ， 但 级 别 比 INFO 低 的 DEBUG 则 不 会 
被 输出 。 







































































在 Hadoop 源 代码 中 ， 大 部 分 Java 文 件 中 存在 调试 日 志 (DEBUG 级 别 日 志 ) ， 但 默认 情况 下 ， 日 志 级 别 是 INFO。 为 了 查看 更 详细 的 运行 状态 ， 可 
以 下 几 种 方法 打开 DEBUG 日 志 。 
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(1) 使 用 Hadoop Shel 命 令 
































可 使 用 Hadoop 脚 本 中 的 daemonlog 命 令 查 看 和 修改 某 个 类 的 日 志 级 别 ， 比 如 ， 可 通过 以 下 命令 查看 TaskTracker 类 的 日 志 级 别 : 





bin/hadoop daemonlog-getlevel${tasktracker-host}: 50075\ 
org.apache.hadoop.mapred.TaskTracker 

















通过 以 下 命令 将 JobTracker 类 的 日 志 级 别 修改 为 DEBUG: 








bin/hadoop daemonlog-setlevel${tasktracker-host}: 50075\ 
org.apache.hadoop.mapred.TaskTracker DEBUG 



































其 中 ，tasktracker-host 为 TaskTracker 的 host，50075 是 TaskTracker 的 HTTP 端 口号 








lon 


其 他 服务 的 HITP 端 口号 可 参考 附录 B) o 











(2) 通过 Web 界 面 









































j 户 可 以 通过 Web 界 面 查看 和 修改 某 个 类 的 日 志 级 别 ， 比 如 ， 可 通过 以 下 URL 修 改 TaskTracker 类 的 日 志 级 别 : 








http://${tasktracker-host}: 50075/logLevel 





(3) 修改 og4j.properties 文 件 





以 上 两 种 方法 














:能 暂时 修改 日 志 级 别 。 当 Hadoop 重 启 后 会 被 
中 添加 以 下 配置 选项 : 











win) 



























































置 ， 如 果 要 永久 性 改变 日 志 级 别 ， 可 在 目标 节点 配置 目录 下 的 log4j.properties 文 件 








log4j.logger.org.apache.hadoop.mapred. TaskTracker=DEBUG 




















此 外 ， 有 时 为 了 专门 调试 某 个 Java 文 件 ， 需 要 把 该 文件 的 相关 日 志 输出 到 一 个 单独 文件 中 ， 可 在 log4j.properties 中 添加 以 下 内 容 ; 















































# 定 义 输出 方式 为 自 定义 的 TTOUT 
log4j.logger. prg, apache. hadoop.mapred.TaskTracker=DEBUG, TTOUT 
# 设 置 TTOUT 的 输出 方式 为 输出 到 文件 
log4j.appender.TTOUT=org. apache. 1log4j.FileAppender 
# 设 置 文件 路 径 
log4j .appender.TTOUT.File=$ {hadoop.log.dir}/TaskTracker.log 
eee 局 

g4j.appender.TTOUT. layout=org.apache.log4j.PatternLayout 
HPL TOS 
log4j.appender.TTOUT. 





Layout .ConversionPattern=%sd{ISO8601}%p%c: %m%n 





这 些 配置 选项 会 把 TaskTrackerjava 中 的 DEBUG 日 志 写 到 日 志 目 录 下 的 TaskTrackerlog 文 件 

















在 阅读 源 代码 的 过 程 中 ， 
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为 了 跟踪 某 个 变量 值 的 变化 ， 读 者 可 能 需要 自己 添加 一 些 DEBUG 日 志 。 在 Hadoop 源 代码 中 ， 大 部 分 类 会 定义 
打印 对 象 。 通 过 该 对 象 ， 可 打印 各 个 级 别 的 日 志 。 比 如 ， 在 JobTracker 中 
































以 下 代码 定义 对 象 LOG: 





个 














public static final Log LOG=LogFactory.getLog (JobTracker.class) 






































户 可 使 用 LOG 对 象 打印 调 斌 日志， 比如， 可 在 JobTracker 的 main 函 数 首 行 添加 以 下 代码 : 























LOG.debug ("Start to lauch JobTracker.....") ; 








然后 重新 编译 Hadoop 源 代码 ， 并 将 org.apache.hadoop.mapred.JobTracker 的 调试 级 别 修改 为 DEBUG， 














limh 














新 启动 Hadoop 后 便 可 以 看 到 该 








[1] Apache log4j 网 址 : http//logging apache.org/log4j/index.html 





调试 信息 。 





I7 2h 





搭建 一 个 高 效 的 源 代码 学 习 环 境 是 深入 学 习 Hadoop 的 良好 开端 ， 本 章 主 要 内 容 正 是 帮助 读者 搭建 一 个 这 样 的 学 习 环 境 。 在 


作者 看 来 ， 一 个 高 效 的 Hadoop 学 习 环 境 至 少 应 该 包括 源 代码 阅读 环境 、Hadoop 使 用 环境 和 源 代码 编译 调试 环境 ， 而 本 章 正 是 转 
绕 这 三 个 环境 的 搭建 方法 编写 的 。 







































































本 章 首 先 分 别 介绍 了 在 Linux 和 Windows 环 境 下 搭建 Hadoop 源 代码 阅读 环境 的 方法 ;在 此 基础 上 ， 进 一 步 介绍 了 Hadoop 的 基本 
使 用 方法 ， 主 要 涉及 Hadoop Shel 和 Eclipse 插件 两 种 工具 的 使 用 ， 最 后 介绍 了 Hadoop 源 代码 编译 和 调试 方法 ， 其 中 ， 调 试 方法 主要 
介绍 了 使 用 Eclipse 远程 调试 和 打印 调试 日 志 两 种 。 
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第 2 章 ”MapReduce 设 计 理 念 与 基本 架构 









































第 1 章 介绍 了 Hadoop 学 习 环境 的 搭建 方法 ， 这 是 学 习 Hadoop 需 要 进行 的 最 基本 的 准备 工作 。 而 在 这 一 章 中 ， 我 们 将 从 设计 理 
念 和 基本 架构 方面 对 Hadoop MapReduce 进 行 介绍 ， 同 样 ， 这 属于 准备 工作 的 一 部 分 。 通 过 本 章 的 介绍 将 会 为 后 面 几 章 深入 剖析 
MapReduce 内 部 实现 葛 定 基础 。 


























































































































MapReduce 是 一 个 分 布 式 计算 框架 ， 主 要 由 两 部 分 组 成 : 编程 模型 和 运行 时 环境 。 其中， 编程 模型 为 用 户 提 供 了 非常 易 用 的 
编程 接口 ， 用 户 只 需要 像 编 写 串 行程 序 一 样 实现 几 个 简单 的 函数 即 可 实现 一 个 分 布 式 程序 ， 而 其 他 比较 复杂 的 工作 ， 如 节点 间 的 
通信 、 节 点 失效 、 数 据 切 分 等 ， 全 部 由 MapReduce 运 行 时 环境 完成 ， 用 户 无 须 关 心 这 些 细节 。 在 本 章 中 ， 我 们 将 从 设计 目标 、 编 
程 模型 和 基本 架构 等 方面 对 MapReduce 框 架 进 行 介绍 。 



















































































































































































2.1 Hadoop 发 展 史 


2.1.1 Hadoop 产 生 背 景 








Hadoop 最 早起 源 于 Nutchl] 。Nutch 是 一 个 开源 的 网 络 搜索 引擎 ， 由 Doug Cutting 于 2002 年 创建 。Nutch 的 设计 目标 是 构建 一 个 
大 型 的 全 网 搜索 引擎 ， 包 括 网 页 抓 取 、 索 引 、 查 询 等 功能 ， 但 随 着 抓 取 网 页 数量 的 增加 ， 遇 到 了 严重 的 可 扩展 性 问题 ， 即 不 能 解 
决 数 十 亿 网 页 的 存储 和 索引 问题 。 之 后 ， 谷 歌 发 表 的 两 篇 论文 为 该 问题 提供 了 可 行 的 解决 方案 。 一 篇 是 2003 年 发 表 的 关于 谷歌 分 
布 式 文件 系统 (GFO) 的 论文 站。 该 论文 描述 了 谷歌 搜索 引 警 网 页 相关 数据 的 存储 架构 ， 该 架构 可 解决 Nutch 遇 到 的 网 页 抓 取 和 
索引 过 程 中 产生 的 超大 文件 存储 需求 的 问题 。 但 由 于 谷歌 仅 开 源 了 思想 而 未 开源 代码 ，Nutch 项 目 组 便 根 据 论 文 完成 了 一 个 开源 
实现 ， 即 Nutch 的 分 布 式 文件 系统 (NDFS) 。 另 一 篇 是 2004 年 发 表 的 关于 谷歌 分 布 式 计算 框架 MapReduce 的 论文 Bl 。 该 论文 描述 
了 谷歌 内 部 最 重要 的 分 布 式 计算 框架 MapReduce 的 设计 艺术 ， 该 框架 可 用 于 处 理 海量 网 页 的 索引 问题 。 同 样 ， 由 于 谷歌 未 开源 代 
码 ，Nutch 的 开发 人 员 完 成 了 一 个 开源 实现 。 由 于 NDFS 和 MapReduce 不 仅 适用 于 搜索 领域 ，2006 年 年 初 ， 开 发 人 员 便 将 其 移出 
























































































































































































































































Nutch， 成 为 Lucene [的 一 个 子 项 目 ， 称 为 Hadoop。 大 约 同 一 时 间 ，Doug Cutting 加 入 雅虎 公司 ， 且 公司 同意 组 织 一 个 专门 的 团队 
继续 发 展 Hadoop。 同 年 2 月 ，Apache Hadoop 项 目 正 式 启动 以 文 持 MapReduce 和 HDFS 的 独立 发 展 。2008 年 1 月 ，Hadoop 成 为 Apache 
顶级 项 目 ， 迎 来 了 它 的 快速 发 展期 。 









































[1] httpynutch. apache.org/ 

论文: Sanjay Ghemawat, Howard Gobioff Shun-Tak Leung, “The Google file system’, Proceedings of the nineteenth ACM Symposium on 
Operating Systems Principles. 

[3] 论文 : JDean and S.Ghemawat, “Mapreduce: simplified data processing on large clusters”, Proceedings of the 6th Conference on 
Symposium on Opearting Systems Designé& Implementation. 

[4] http//lucene. apache.org/. 


2.1.2 Apache Hadoop 新 版 本 的 特性 














当前 Apache Hadoop 版 本 非常 多 ， 本 小 节 将 帮助 读者 梳理 各 个 版 本 的 特性 以 及 它们 之 间 的 联系 。 在 讲解 Hadoop 各 版 本 之 前 ， 
先 要 了 解 Apache 软 件 发 布 方式 。 对 于 任何 一 个 Apache 开 源 项 目 ， 所 有 的 基础 特性 均 被 添加 到 一 个 称 为 "trunk 的 主 代 码 线 Cain 




















codeline) 。 当 需要 开发 某 个 重要 的 特性 时 




































































， 会 专门 从 主 代 码 线 中 延伸 出 一 个 分 支 branch) ， 这 被 称 为 一 个 候选 发 布 版 









































(candidate release) 。 该 分 支 将 专注 于 开发 该 特性 而 不 再 添加 其 他 新 的 特性 ， 待 基本 bug 修 复 之 后 ， 经 过 相关 人 士 投票 便 会 对 外 公 
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大 特性 : 





成 为 发 布 版 (release version) ， 并 将 该 4 
的 分 支 可 能 先 于 版 本 低 的 分 支 发 布 。 











于 Apache 以 特性 为 准 延伸 新 的 分 支 ， 故 在 介绍 Apache Hadoop 版 本 之 前 ， 先 介绍 几 个 独立 产生 的 Apache Hadoop 新 版 本 的 重 


























村 性 合并 到 主 代 码 线 中 。 需 要 注意 的 是 ， 多 个 分 支 可 能 会 同时 进行 研发 ， 这 样 ， 版 本 高 




















Q Append !!!; HDFS Append 主 要 完成 


一 个 设计 目标 是 支持 MapReduce 编 程 模型 ， 

















追加 文件 内 容 的 功能 ， 也 就 是 允许 用 户 以 append 方 式 修改 HDFS 上 的 文件 。HDFS 最 初 的 

















而 该 模型 只 需要 写 一 次 文件 ， 之 后 仅 进行 读 操作 而 不 会 对 其 修改 ， 即 “write-once-read- 





many”， 这 就 不 需要 支持 文件 追加 功能 。 但 随 着 HDFS 变 得 流行 ， 一 些 具 有 写 需求 的 应 用 想 以 HDFS 作 为 存储 系统 ， 比 如 ， 有 些 应 
































程序 需要 往 HDFS 上 某 个 文 但 
































F} 中 追加 日 志 信息 ，HBase 需 使 用 HDFS 具 有 的 append 功 能 以 防止 数据 丢失 中等。 








QHDFS RAID I: Hadoop RAID 模 块 在 HDFS 之 上 构建 了 一 个 新 的 分 布 式 文件 系统 :Distributed Raid FileSystem (DRFS) . i% 














系统 采用 了 Erasure Codes 增 强 对 数 








省 大 量 存储 空间 。 





口 Symlink :让 HDFS 支 























居 的 保护 。 有 了 这 样 的 保护 ， 可 以 采用 更 少 的 副本 数 来 保持 同样 的 可 用 性 保障 ， 进 而 为 用 户 节 





























寺 符 号 链接 。 





录 (目标 文件 





VY 





T Security’! ，Hadoop 的 HDFS 和 MapReduce 均 缺乏 相应 的 安全 机 制 ， 比 如 在 HDFS 中 ， 用 户 只 要 知道 某 个 block 的 blockID， 便 
可 以 绕 过 NameNode 直 接 从 DataNode 上 读 取 该 block， 用 户 可 以 向 任意 DataNode 上 写 block; 在 MapReduce 中 ， 用 户 可 以 修改 或 者 删 















































。 当 程序 向 符号 


符号 链接 是 一 种 特殊 的 文件 ， 它 以 绝对 或 者 相对 路 径 的 形式 指向 另外 一 个 文件 或 者 



































链接 中 写 数据 时 ， 相 当 于 直接 向 目标 文件 中 写 数 据 。 








































































































掉 任意 其 他 用 户 的 作业 等 。 为 了 增强 Hadoop 的 安全 机 制 ， 从 2009 年 起 ，Apache 专 门 组 成 一 个 团队 ， 为 Hadoop 增 加 基于 Kerberos 和 
Deletion Token 的 安全 认证 和 授权 机 制 。 








口 MRv1: 第 一 代 MapReduce 计 算 框架 。 
environment) 。 它 的 基本 编程 模型 是 将 问题 抽象 成 Map 和 Reduce 两 个 阶段 。 其 中 ，Map 阶 段 将 输入 数据 解析 成 key/value， 和 迭代 调用 


map0 函 数 处 理 后 ， 再 以 key/value 的 形式 输出 到 本 





















































部 分 组 成 : 编程 模型 Cprogrammingmodel) 和 运行 时 环境 (runtime 


ČI 



























































目录 ，Reduce 阶 段 则 将 key 相 同 的 value 进 行规 约 处 理 ， 并 将 最 终结 果 写 到 HDFS 








= 





上 。 它 的 运行 时 环境 由 两 类 服务 组 成 : JobTracker 和 TaskTracker， 其 中 ，JobTracker 负 责 资源 管理 和 所 有 作业 的 控制 ， 而 











TaskTracker 负 责 接收 来 自 JobTracker 的 命令 3 











执行 它 。 





























口 YARN/MRV2: 针对 MRv1 中 的 MapReduce 在 扩展 性 和 多 框架 支持 方面 的 不 足 ， 提 出 了 全 新 的 资源 管理 框架 YARN (Yet 
Another Resource Negotiator) 。 它 将 JobTracker 中 的 资源 管理 和 作业 控制 功能 分 开 ， 分 别 由 两 个 不 同 进程 ResourceManager 和 
ApplcationMaster 实 现 。 其 中 ，ResourceManager 负 责 所 有 应 用 程序 的 资源 分 配 ， 而 ApplcationMaster 仅 负责 管理 一 个 应 用 程序 。 





口 NameNode Federation1 | : 针对 Hadoop 1.0 中 NameNode 内 存 约 束 限 秆 
展 成 多 个 ， 其 中 ， 每 个 NameNode 分 管 一 部 分 目录 。 这 不 仅 增强 了 HDFS 扩 展 性 ， 也 使 HDFS NameNode 具 备 了 隔离 性 。 








口 NameNode HA1 | : HDFS NameNode 存 在 两 个 问题 ， 即 NameNode 内 存 约束 限制 扩展 性 和 单 点 故障 。 其 中 ， 第 一 个 问题 通 
过 NameNode Federation 方 案 解 决 ， 而 第 二 个 问题 由 
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其 扩展 性 问题 提出 的 改进 方案 。 它 将 NameNode 横 向 扩 











































































































通过 NameNode 热 备 方案 〈 即 NameNode HA) 实现 。 


=. 











[1] 0.20-append: _https://issues.apache.org/jira/browse/HDFS-200, 0.21.0-append: https://issues.apache.org/jira/browse/HDFS-265 
[2] http//hbase. apache.org/book/hadoop.html 

[3] http//wiki. apache.org/hadoop/HDFS-RAID9https‘//issues.apache. org/jira/browse/HDFS-503 

[4] https//issues. apache. org/jira/browse/HDFS-245 

[5] https//issues. apache. org/jira/browse/HADOOP-4487 

[6] https//issues. apache. org/jira/browse/HDFS- 1052 

[7] https//issues. apache. org/jira/browse/HDFS- 1623 


2.1.3 ”Hadoop 版 本 变迁 





到 2012 年 5 月 为 止 ，Apache Hadoop 已 经 出 现 四 个 大 的 分 支 ， 如 图 2-1 所 示 。 





Apache Hadoop 的 四 大 分 支 构 成 了 四 个 系列 的 Hadoop 版 本 。 


1.0.20.X 系 列 











0.20.2 版 本 发 布 后 ， 几 个 重要 的 特性 没有 基于 trunk 而 是 在 0.20.2 基 础 上 继续 研发 。 值 得 一 提 的 主要 有 两 个 特性 : Append 与 
Security。 其 中 ， 含 Security 特 性 的 分 支 以 0.20.203 版 本 发 布 ， 而 后 续 的 0.20.205 版 本 综合 了 这 两 个 特性 。 需 要 注意 的 是 ， 之 后 的 
1.0.0 版 本 仅 是 0.20.205 版 本 的 重 命名 。0.20.X 系 列 版 本 是 最 令 用 户 感到 疑惑 的 ， 因 为 它们 具有 的 一 些 特 性 ，trunk 上 没有 ;， i 
之 ，trunk 上 有 的 一 些 特 性 ，0.20.X 系 列 版 本 却 没 有 。 




























































































2.0.21.0/0.22.X 系 列 








这 一 系列 版 本 将 整个 Hadoop 项 目 分 割 成 三 个 独立 的 模块 ， 分 别 是 Common、HDFS 和 MapReduce。HDFS 和 MapReduce 都 对 
Common 模 块 有 依赖 性 ， 但 是 MapReduce 对 HDFS 并 没有 依赖 性 。 这 样 ，MapReduce 可 以 更 容易 地 运行 其 他 分 布 式 文件 系统 ， 同 
时 ， 模 块 间 可 以 独立 开发 。 具 体 各 个 模块 的 改进 如 下 。 

















口 Common 模 块 : 最 大 的 新 特性 是 在 测试 方面 添加 了 Larse-Scale Automated TestFramework1!| 和 Fault Injection Framework [| 。 

















OHDFS 模 块 : 主要 增加 的 新 特性 包括 支持 妃 加 操作 与 建立 符号 连接 、SecondaryNameNode 改 进 〈Secondary NameNode 被 易 
除 ， 取 而 代 之 的 是 Checkpoint Node， 同 时 添加 一 个 Backup Node 的 角色 ， 作 为 NameNode 的 冷 备 ) 、 人 允许 用 户 自 定义 block 放 置 算法 





















































口 MapReduce 模 块 ， 在 作业 API 方 面 ， 开 始 启动 新 MapReduce API， 但 老 的 API 仍 然 章 




















0.22.0 在 0.21.0 的 基础 上 修复 了 一 些 bug 并 进行 了 部 分 优化 。 


Truck development (source of new features ) 
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图 2-1 Hadoop 版 本 变迁 图 日 





3.0.23.X 系 列 














0.23.X 是 为 了 克服 Hadoop 在 扩展 性 和 框架 通用 性 方 国 
































的 不 足 而 提出 来 的 。 它 实际 上 是 一 个 全 新 的 平台 ， 包 括 分 布 式 文件 系统 











HDFS Federation 和 资源 管理 框架 YARN 两 部 分 ， 可 对 接 入 的 各 种 计算 框架 〔 如 MapReduce、Spark 四 等 ) 进行 统一 管理 。 


























版 自 带 MapReduce 库 ， 而 该 库 集成 了 迄今 为 止 所 有 的 MapReduce 新 特性 。 


4.2.X 系 列 








它 的 发 行 











同 0.23.X 系 列 一 样 ，2.X 系 列 也 属于 下 一 代 Hadoop。 与 0.23.X 系 列 相 比 ，2.X 系 列 增加 了 NameNode HA 和 Wire-compatibility 等 新 








特性 。 





表 2-1 总 结 了 Hadoop 各 个 发 布 版 的 特性 以 及 稳定 性 。 


Hadoop 各 个 发 布 版 的 特性 以 及 稳定 性 
特性 


Append | RAID | Symlink | Security | MRv1l YARN NameNods 
ý Federation 


表 2-1 
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2010 


2011 
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个 稳定 的 版 本 ， 再 有 其 为 1.0.0， 





Ly 里程 











本 书 之 所 以 以 分 析 Apache Hadoop 1.0.0 为 主 ， 主 要 是 因为 这 
布 这 个 版 本 ， 也 是 希望 该 版 本 成 为 业界 的 规范 。 需 要 注意 的 是 ， 
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于 所 有 Apache Hadoop 1.X 版 本 19 。 





[1] 参考 httpsV/issues.apache.orgyjira/browse/HADOOP-6332 
[2] B% http/hadoop.apache. org/hdf§/docs/r0.21.0/faultinject_framework. html 

[3] 图 片 修改 自 : httpyvww.cloudera.convblog/2012/01/an-update-on-apache-hadoop-1-0/ 
[4] Spark 是 一 种 内 存 计算 框架 ， 支 持 迭 代 式 计算 ， 主 页 是 http//www.spark-project.org/. 
[5] 0.22.0 版 本 中 只 有 HDFS Security， 没 有 MapReduce Security. 

[6] 不 同 版 本 之 间 细 节 可 能 稍 有 不 同 ， 此 时 以 Hadoop 1.0.0 版 本 为 了 
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尽管 本 书 以 分 析 Apache Hadoop 1.0.0 版 本 为 主 ， 但 本 书 内 容 适 用 


碑 意 义 。Apache 发 























2.2 Hadoop MapReduce 设 计 目 标 





















































总 结 Hadoop MapReduce 设 计 目标 ， 主 要 有 以 下 几 个 。 















































通过 上 一 节 关 于 Hadoop MapReduce 历 史 的 介绍 我 们 知道 ，Hadoop MapReduce 诞 生 于 搜索 领域 ， 主 要 解决 搜索 引擎 面临 的 海 
量 数据 处 理 扩展 性 差 的 问题 。 它 的 实现 很 大 程度 上 借鉴 了 谷歌 MapReduce 的 设计 思想 ， 包 括 简化 编程 接口 、 提 高 系统 容错 性 等 。 






































口 易 于 编程 :传统 的 分 布 式 程序 设计 (如 MPI) 非常 复杂 ， 用 户 需要 关注 的 细节 非常 多 ， 比 如 数据 分 片 、 数 据 传输 、 节 点 间 





















































注 的 设计 细节 抽象 成 公共 模块 并 交 
了 开发 效率 。 









































口 良 好 的 扩展 性 : 随 着 公司 业务 的 发 
现 有 的 集群 可 能 已经 无 法 满足 其 计算 能 为 包 


























通信 等 ， 因 而 设计 分 布 式 程序 的 门槛 非常 高 。Hadoop 的 一 个 重要 设计 目标 便 是 简化 分 布 式 程序 设计 ， 将 所 有 并 行程 序 均 需 要 关 


























系统 实现 ， 而 用 户 只 需 专注 于 自己 的 应 用 程序 逻辑 实现 ， 这 样 简化 了 分 布 式 程序 设计 且 提 高 

















口 高 容错 性 : 在 分 布 式 环境 下 ， 随 着 集群 规模 的 增加 ， 
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展 ， 积 累 的 数据 各 


《如 搜索 公司 的 网 页 量 ) 会 越 来 越 大 ， 当 数据 量 增加 到 一 定 程度 后 ， 














信和 失败 等 硬件 故障 和 坏 数 据 或 者 用 户 程序 bug 产 生 的 软 伯 








此 ，Hadoop 通 过 计算 迁移 或 者 数据 迁 

















[存储 能 力 ， 这 时 候 管 理 员 可 能 期 望 通过 添加 机 器 以 达到 线性 扩展 集群 能 力 的 目的 。 


























{uy 





集群 中 的 故障 率 〈 这 里 的 “故障 ' 钨 括 磁盘 损坏 、 机 器 宕 机 、 节 点 间 通 


























故障) 会 显著 增加 ， 进 而 导致 任务 失败 和 数据 丢失 的 可 能 性 增加 。 为 














移 等 策略 提高 集群 的 可 用 性 与 容错 性 。 











2.3 ”MapReduce 编 程 模型 概述 


2.3.1 MapReduce 编 程 模型 简介 








从 MapReduce 自 身 的 命名 特点 可 以 看 出 ，MapReduce 
数 ， 即 可 完成 简单 的 分 布 式 程序 的 设计 。 






































map0O 函 数 以 keyvalue 对 作为 输入 ， 产 生 另 外 一 系列 keyvalue 对 作为 中 间 输 昌 
间 数 据 按照 key 值 进行 聚集 ， 且 key 值 相同 ¢ 


teduce0 函 数 处 理 。 




































































由 两 个 阶段 组 成 : Map 和 Reduce。 月 


上 写 入 本 地 磁盘 。MapReduce 相 
j 户 可 设 定 聚 集 策 略 ， 默 认 情况 下 是 对 key 值 进行 哈 希 取 模 ) 的 数据 被 统一 交 给 





明 户 只 需 编写 map0 和 TeduceO 两 个 函 





医 架 会 自动 将 这 些 中 











经 合 








teduce0 函 数 以 key 及 对 应 的 value 列 表 作 为 输入 ， 后 ， 





key 相 同 的 value 什 














产生 另外 一 系列 key/value 对 作为 最 终 输 出 写 入 





HDFS. 








下 面 以 MapReduce 中 的 “hello world' 程 序 一 一 WordCount 为 例 介 绍 和 




















“hello world’ 程序 是 我 们 学 习 任何 一 门 编程 语言 编写 的 第 一 个 程序 。 








已 简单 且 易于 到 


序 设计 方法 。 





E 解 ， 能 够 帮助 读者 快速 入 门 。 同 样 ， 分 布 





式 处 理 
中 ， 可 以 这 样 编写 〈 伪 代码 ) 。 











其 中 Map 部 分 如 下 : 


EEA H Eh helo worl? 程 序 ，WordCount。 它 完成 的 功能 是 统计 输入 文 伯 











FF 中 











的 每 个 单词 








现 的 次 数 。 在 MapReduce 











//key: 字符 串 偏 移 量 
//value: 一 行 字符 串 内 容 

map (String key, String value) : 
/ ABER SY LE 
words=SplitIntoTokens (value) ; 
for each word w in words: 
EmitIntermediate (w, "1") ; 

















Reduce 部 分 如 下 : 





//key: 一 个 单词 
//values: 该 单词 
reduce (String key, 
int result=0; 

for each v in values: 
result+=StringToInt (v) ; 

Emit (key, IntToString (result) ) ; 








bt 现 的 次 数列 表 


Iterator values) : 
































户 编 写 完 MapReduce 程 序 后 ， 按 照 一 定 的 规则 指定 程序 的 输入 和 输出 目录 ， 并 提交 到 Hadoop 集 群 中 。 作 业 在 Hadoop 中 的 执 











=> 





了 过 程 如 图 2-2 所 示 。Hadoop 将 输入 数据 切 分 成 若干 个 输入 分 片 Gnput split, Ja H 


简称 splt) ， 并 将 每 个 sptt 交 给 一 个 Map Task 处 

















理 ，Map Task 不 断 地 从 对 应 的 split 中 解析 出 一 个 个 keyvalue， 
HEATH (partition) 写 到 本 地 磁盘 ， 同 时 ， 


序 的 方法 将 key 相 同 的 数据 聚集 在 一 起 ， 调 用 reduceO 函 数 处 至 





并 调用 map0 函 数 处 ] 









































EE， 并 将 结果 输出 到 








每 个 Reduce Task 从 每 个 Map Task 上 读 取 属 于 自己 的 那个 partiion， 然 后 使 用 





里 ， 处 理 完 之 后 根据 Reduce Task 个 数 将 结果 分 成 
基于 

















PHF 











文件 中 。 


split map task 
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图 2-2 WordCount 程 序 运 行 过 程 


group by sorting 
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细心 的 读者 可 能 注意 到 ， 上 面 的 程序 还 缺少 三 个 基本 的 组 件 ， 功 能 分 别 是 : 中 指定 输入 文件 格式 。 将 输入 数据 切 分 成 若干 个 
spit， 且 将 每 个 sptt 中 的 数据 解析 成 一 个 个 map0 函 数 要 求 的 keyvalue 对 。 四 确定 map0 函 数 产生 的 每 个 keyvalue 对 发 给 哪个 Reduce 























Task 函 数 处 理 。@ 指 定 输出 文件 格式 ， 即 每 个 key/value 对 以 何 种 用 








在 Hadoop MapReduce 中 ， 这 三 个 组 件 分 别 是 InputFormat、Partitioner 和 OutputFormat， 它 们 均 需 要 用 户 根 据 
置 。 而 对 于 上 面 的 WordCount 例 子 ， 默 认 情 况 下 Hadoop 采 用 的 默认 实现 ] 





























综 上 所 述 ，Hadoop MapReduce 对 外 提供 了 5 个 可 编程 组 
。 本 书 将 在 第 3 章 中 详细 介绍 它们 的 设计 思路 以 及 扩展 实现 
































[1] 还 有 一 个 组 件 是 Canbiner， 它 通常 用 于 优化 MapReduce 程 序 性 能 ， 但 不 属于 必 备 组 伯 




















多 式 保 存 到 输出 文件 中 。 














E 好 可 以 满足 要 求 ， 因 而 不 必 再 提供 。 


























9 己 的 应 用 需求 配 








件 ， 分 别 是 InputFormat、Mapper、Partitioner、Reducer 和 OutputFormat !!! 


© 








2.3.2 ”MapReduce 编 程 实例 














MapReduce 能 够 解决 的 问题 有 一 个 共同 特点 ; 任务 可 以 被 分 解 为 多 个 子 问 题 ， 且 这 些 子 问题 相对 独立 ， 彼 此 之 间 不 会 有 牵 
制 ， 竺 并行 处 理 完 这 些 子 问题 后 ， 任 务 便 被 解决 。 在 实际 应 用 中 ， 这 类 问题 非常 庞大 ， 谷 歌 在 论文 中 提 到 了 MapReduce 的 一 些 典 
型 应 用 ， 包 括 分 布 式 gep、URL 访 问 频率 统计 、Web 连 接 图 反 转 、 倒 排 索引 构建 、 分 布 式 排序 等 ， 这 些 均 是 比较 简单 的 应 用 。 下 


DWA 
面 介绍 一 些 比较 复杂 的 应 用 。 



































































































































(1) Top 开 问题 





在 搜索 引擎 领域 中 ， 常 常 需要 统计 最 近 最 热门 的 K 个 查询 词 ， 这 就 是 典型 的 “Top K" 问 题 ， 也 就 是 从 海量 查询 中 统计 出 现 频 
率 最 高 的 前 K 个 。 该 问题 可 分 解 成 两 个 MapReduce 作 业 ， 分 别 完成 统计 词 频 和 找 出 词 频 最 高 的 前 K 个 查询 词 的 功能 。 这 两 个 作业 
存在 依赖 关系 ， 第 二 个 作业 需要 依赖 前 一 个 作业 的 输出 结果 。 第 一 个 作业 是 典型 的 WordCount 问 题 。 对 于 第 二 个 作业 ， 首 先 map0 
函数 中 输出 前 K 个 频率 最 高 的 词 ， 然 后 由 reduce0 函 数 汇总 每 个 Map 任 务 得 到 的 前 K 个 查询 词 ， 并 输出 频率 最 高 的 前 K 个 查询 词 。 


































































































(2) K-means#828 
































K-means 是 一 种 基于 距离 的 聚 类 算法 。 它 采用 距离 作为 相似 性 的 评价 指标 ， 认 为 两 个 对 象 的 距离 越 近 ， 其 相似 度 就 越 大 。 该 
算法 解决 的 问题 可 抽象 成 : 给 定 正 整数 K 和 N 个 对 象 ， 如 何 将 这 些 数据 点 划分 为 K 个 聚 类 ? 






























































该 问题 采用 MapReduce 计 算 的 思路 如 下 : 首先 随机 选择 K 个 对 象 作为 初始 中 心 点 ， 然 后 不 断 欠 代 计算 ， 直 到 满足 终止 条 件 
(达到 迭代 次 数 上 限 或 者 数据 点 到 中 心 点 距离 的 平方 和 最 小 ) 。 在 第 ]I 轮 迭代 中 ，map0 函 数 计算 每 个 对 象 到 中 心 点 的 距离 ， 选 择 
距 每 个 对 象 〈object) 最 近 的 中 心 点 (center point) ， 并 输出 二 center poinb object> 对 。reduce0 函 数 计算 每 个 聚 类 中 对 象 的 距离 均 
值 ， 并 将 这 K 个 均值 作为 下 一 轮 初始 中 心 点 。 
























































G) 贝 叶 斯 分 类 









































贝 叶 斯 分 类 是 一 种 利用 概率 统计 知识 进行 分 类 的 统计 学 分 类 方法 。 该 方法 包括 两 个 步骤 : 训练 样本 和 分 类 。 其 实现 由 多 个 
MapReduce 作 业 完 成 ， 具 体 如 图 2-3 所 示 。 其 中 ， 训 练 样本 可 由 三 个 MapReduce 作 业 实 现 : 第 一 个 作业 〈Extractob) 抽取 文档 特 
征 ， 该 作业 只 需要 Map 即 可 完成 ， 第 二 个 作业 〈ClassPriorJob) 计算 类 别 的 先 验 概率 ， 即 统计 每 个 类 别 中 文档 的 数目 ， 并 计算 类 
别 概率 ; 第 三 个 作业 (ConditionalProbiltyJob〉 计 算 单词 的 条 件 概率 ， 即 统计 <label, word> 在 所 有 文档 中 出 现 的 次 数 并 计算 单词 
的 条 件 概率 。 后 两 个 作业 的 有 具体 实现 类 似 于 WordCount。 分 类 过 程 由 一 个 作业 (PredictJob〉 完成。 该 作业 的 map0 函 数 计算 每 个 待 
分 类 文档 属于 每 个 类 别 的 概率 ，reduce0 函 数 找 出 每 个 文档 概率 最 高 的 类 别 ， 并 输出 二 docid, label> (编号 为 docid 的 文档 属于 类 别 
label) 。 




































































































































































| 


















Training 
Document 









ConditionalProbilityJob 


ClassPriorJob 
Predictlob 


Labeled 
Document 


图 2-3 朴素 贝 叶 斯 分 类 算法 在 MapReduce 上 实现 






































前 面 介 绍 的 是 MapReduce 可 以 解决 的 一 些 问题 。 为 了 便于 读者 更 深刻 地 理解 MapReduce， 下 面 介 绍 MapReduce 不 能 解决 或 者 
惟 以 解决 的 一 些 问 题 。 
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1) Fibonaccištfii St. Fibonacci, PAAR mAT N RER HEL, ARZ a ot 
个 互 不 相干 的 子 问 题 ， 因 而 不 能 用 MapReduce 解 决 。 






















































































2) 层次 聚 类 法 。 层 次 聚 类 法 是 应 用 最 广泛 的 聚 类 算法 之 一 。 层 次 聚 类 法 采用 迭代 控制 策略 ， 使 聚 类 逐步 优化 。 它 按照 一 定 
的 相似 性 (一般 是 距离 》 判 断 标准 ， 合 并 最 相似 的 部 分 或 者 分 割 最 不 相似 的 部 分 。 按 采用 “ 自 顶 向 下 ”和 “ 自 底 向 上 "两 种 方式 ， 可 
将 其 分 为 分 解 型 层次 聚 类 法 和 聚 结 型 层次 聚 类 法 两 种 。 以 分 解 型 层次 聚 类 算法 为 例 ， 其 主要 思想 是 ， 开 始 时 ， 将 每 个 对 象 归 为 一 
类 ， 然 后 不 断 迭 代 ， 直 到 所 有 对 象 合并 成 一 个 大 类 (或 者 达到 某 个 终止 条 件 ) ; 在 每 轮 迭 代 时 ， 需 计算 两 两 对 象 间 的 距离 ， 并 合 
并 距离 最 近 的 两 个 对 象 为 一 类 。 该 算法 需要 计算 两 两 对 象 间 的 距离 ， 也 就 是 说 每 个 对 象 和 其 他 对 象 均 有 关联 ， 因 而 该 问题 不 能 被 
分 解 成 若干 个 子 问 题 ， 进 而 不 能 用 MapReduce 解 决 。 
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2.4 Hadoop 基 本 架构 






































上 








Hadoop 由 两 部 分 组 成 ， 分 别 是 分 布 式 文件 系统 和 分 布 式 计算 框架 MapReduce。 其 中 ， 分 布 式 文件 系统 主要 用 于 大 规模 数据 的 














分 布 式 存储 ， 而 MapReduce 则 构建 在 分 布 式 文件 系统 之 上 ， 对 存储 在 分 布 式 文件 系统 中 的 数据 进 
MapReduce， 但 考虑 到 它 的 一 些 功 能 跟 底层 存储 机 制 相关 ， 因 而 会 首先 介绍 分 布 式 文件 系统 。 














行 分 布 式 计算 。 本 书 主要 涉及 











在 Hadoop 中 ，MapReduce 底 层 的 分 布 式 文件 系统 是 独立 模块 ， 用 户 可 按照 约定 的 一 套 接口 实现 自己 的 分 布 式 文件 系统 ， 然 后 
经 过 简单 的 配置 后 ， 存 储 在 该 文件 系统 上 的 数据 便 可 以 被 MapReduce 处 理 。Hadoop 默 认 使 用 的 分 布 式 文件 系统 是 HDFS (Hadoop 
Distributed File System Hadoop 分 布 式 文件 系统 ) ， 它 与 MapReduce 框 架 紧 密 结合 。 本 节 首 先 介 绍 分 布 式 存 储 系统 HDFS 的 基础 架 
































构 ， 然 后 介绍 MapReduce 计 算 框架 。 


2.4.1 HDFS 架 构 




















HDFS 是 一 个 具有 高 度 容 错 性 的 分 布 式 文件 系统 ， 适 合 部 署 在 廉价 的 机 器 上 。HDFS 能 提供 高 吞吐 量 的 数据 访问 ， 非 常 适 合 大 





























规模 数据 集 上 的 应 用 。 



































HDFS 的 架构 如 图 2-4 所 示 ， 总 体 上 采用 了 masterslave 架 构 ， 主 要 由 以 下 几 个 组 件 组 成 : Client、NameNode、Secondary、 

















NameNode ||! 和 DataNode。 下 面 分 别 对 这 几 个 组 件 进行 介绍 。 


















NameNode 
元 数据 






本 地 磁盘 
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Heartbeat & 
BlockReport 
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| len 








DataNode DataNode DataNode DataNode 


图 2-4 HDFS 架 构图 








(1) Client 





Clent( 代 表 用 户 〉 通 过 与 NameNode 和 DataNode 交 互 访问 HDFS 中 的 文件 。Client 提 供 了 一 个 类 似 POSIX 的 文件 系统 接口 供用 





























户 调用 











(2) NameNode 





> 
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# 中 只 有 一 个 NameNode。 它 是 整个 系统 的 “总管 "负责 管理 HDPS 的 目录 树 和 相关 的 文件 元 数据 信息 。 这 些 


整个 Hadoop 集 群 
息 是 以 “fsimage”(HDFS 元 数据 镜像 文件 ) 和 “edilog”(HDFS 文 件 改动 日 志 〉 两 个 文件 中 形式 存放 在 本 地 磁盘 ， 当 HDFS 重 启 时 重 
发 现 某 个 DataNode 宕 掉 ， 则 将 该 DataNode 移 出 HDFS 


新 构造 出 来 的 。 此 外 ，NameNode 还 负责 监控 各 个 DataNode 的 健康 状态 ， 一 旦 


重新 备份 其 上 面 的 数据 。 





























un 













































































(3) Secondary NameNode 


























居 进 行 热 备份 ， 而 是 定期 合并 fsimage 和 edits 日 志 ， 并 传输 给 


Secondary NameNode 最 重要 的 任务 并 不 是 为 NameNode 元 数据 
要 注意 的 是 ， 为 了 减 小 NameNode 压 力 ，NameNode 自 己 并 不 会 合并 fsimage 和 edits， 并 将 文件 存储 到 磁盘 上 ， 


NameNode。 这 里 需要 

































































而 是 交 由 Secondary NameNode 完 成 。 











(4) DataNode 


存储 ， 并 将 数据 信息 定期 汇报 给 NameNode。DataNode 以 
FEF 内容， 默认 情况 下 block 大 小 为 64MB。 当 用 户 上 传 一 个 大 的 文件 到 HDFS 上 时 ， 该 文件 会 被 
E 数 据 可 靠 ， 会 将 同一 个 block 以 流水 线 方式 写 到 若干 个 (默认 











一 般 而 言 ， 每 个 Slave 节 点 上 安装 一 个 DataNode， 它 负责 实际 的 数 扩 














固定 大 小 的 block 为 基本 单位 组 织 文 伯 
团 分 成 若干 个 block， 分 别 存储 到 不 同 的 DataNode; 同时 ， 为 了 保 订 


是 3， 该 参数 可 配置 ) 不 同 的 DataNode 上 。 这 种 文件 切割 后 存储 的 过 程 是 对 用 户 透明 的 。 
























































[1] ÆHadoop 0.21.0 版 本 中 ，SecondaryNameNode 被 Checkpoint Node 代 
[2] 在 Hadoop 0.21.0 版 本 中 ， 这 两 个 文件 被 合并 成 一 个 。 




















2.4.2 Hadoop MapReduce 架 构 


同 HDFS 一 样 ，Hadoop MapReduce 也 采 月 
JobTracker、TaskTracker 和 Task。 下 面 分别 对 这 几 个 组 件 





C1) Client 
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FAS 





JobTracker3 
务 转移 到 其 他 节点 ; 
MENT, ARAE 


TaskTracker 
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Mk” (Job) 表示 MapReduce 程 序 。 





(2) JobTracker 




















的 任 








(3) TaskTracker 








=> 


4 





Task 分 为 Map Task 和 Reduce Task 两 种 ， 均 | 
据 ， 而 对 于 MapReduce 而 言 ， 其 处 理 单位 是 splt。spkt 与 block 
如 数据 起 始 位 置 、 
目 ， 因 为 每 个 splt 会 交 ! 














(4) Task 





TaskTracker 


Reduce Task 


要 负责 资源 监控 和 作业 调度 。 
同时 ，JobTracker 会 跟踪 任务 的 执行 进度 、 


任务 调 






































数据 长 
一 个 Map Task 人 处 理 。 



























































Heartbeat 






2-5 Hadoop MapReduce 架 构图 














户 编写 的 MapReduce 程 序 通过 Client 提 交 到 JobTracker 端 
一 个 MapReduce 程 序 可 对 应 若 3 























E 务 使 用 这 些 资 源 。 在 Hadoop 中 ， 


会 周期 性 地 通过 Heartbeat 将 本 节点 上 资源 的 使 月 
执行 相应 的 操作 (如 启动 新 任务 、 杀 死 任 
存 等 ) 。 
Map slot 和 Reduce slot 两 种 ， 


务 等 ) 。 





一 个 Task 获 取 到 一 个 slot 后 才 有 机 会 运行 ， 而 Hadoop 调 度 器 的 作用 就 是 
分 别 供 Map Task 和 Reduce Task 使 用 。 














TaskTracker. 

















JobTracker 


Heartbeat 


TaskTracker 


Reduce Task 





JobTracker 监 控 所 有 TaskTracker 与 作业 的 健康 状况 ， 
资源 使 用 量 等 信息 ， 
度 器 是 一 个 可 插 拔 的 模块 ， 








上 情况 和 任务 的 运行 进度 汇报 给 


TaskTracker 使 用 “Slot 等 量 划分 本 节点 上 的 资源 量 。 


H Y Master/Slave (M/S) 架构 ， 有 具体 如 图 2-$ 所 示 。 它 主要 由 以 下 几 个 组 件 组 成 : Client、 








Task 
Scheduler 


Heartbeat 














网 



































TaskTracker 


一 旦 发 现 失 败 情况 后 ， 
将 这 些 信息 告诉 和 有 


Reduce Task 


> 同时 ， 用 户 可 通过 Client 提 供 的 一 些 接 口 查 看 作业 运行 状态 。 在 Hadoop 内 部 
F 个 作业 ， 而 每 个 作业 会 被 分 解 成 若 








于 个 Map/Reduce 任 务 (Task) 。 





其 会 将 相应 的 任 
E 务 调度 器 ， 而 调度 器 会 在 资源 出 








































































































TaskTracker 通 过 


启动 。 从 上 一 小 节 中 我 们 知道 
的 对 应 关系 如 图 2-6 所 示 。 











度 、 数 据 所 在 节点 等 。 











它 的 划分 方法 完全 









































slot 数 目 ( 可 配置 参数 ) 

















用 户 自己 决定 。 但 需要 注意 的 是 ， 








将 各 个 TaskTracker 上 的 空 





j 户 可 以 根据 自己 的 需要 设计 相应 的 调度 器 。 





从 JobTracker， 同 时 接收 JobTracker 发 送 过 来 的 


“Slot 代表 计算 资源 〈《CPU、 内 
闲 slot 分 配给 Task 使 用 。slot 分 为 
限定 Task 的 并 发 度 。 























，HDFS 以 固定 大 小 的 block 为 基本 单位 存储 数 
spjt 是 一 个 逻辑 概念 








， 它 只 包含 一 些 元 数据 信息 ， 比 
split) & 2> tae T Map Task 的 数 








block? 
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| split 1 | split 2 | split 3 | split4 | 
| | | | | 


2-6 splt 与 block 的 对 应 关系 








Map Task 执 行 过 程 如 图 2-7 所 示 。 由 该 图 可 知 ，Map Task 先 将 对 应 的 spjt 迭 代 解 析 成 一 个 个 keyvalue 对 ， 依 次 调用 用 户 自 定义 的 map() 函 
数 进行 处 理 ， 最 终 将 临时 结果 存放 到 本 地 磁盘 上 ， 其 中 临时 数据 被 分 成 若干 个 partition， 每 个 partition 将 被 一 个 Reduce Task 处 理 。 





























Map Task 


Input blocks 








图 2-7 Map Task 执 行 流程 


Reduce Task 执 行 过 程 如 图 2-8 所 示 。 该 过 程 分 为 三 个 阶段 四 从 远程 节点 上 读 取 Map Task 中 间 结 果 《〈 称 为 "Shuffe 阶 段 ?》” ;名 按照 key 对 
key/Value 对 进行 排序 ( 称 为 “Sort 阶 段 ”) ; @ 依 次 读 取 二 key, value lst> ， 调 用 用 户 自 定义 的 reduce0 函 数 处 理 ， 并 将 最 终结 果 存 到 HDFS 上 
( 称 为 ‘Reduce 阶 段 ”) 。 

























Reduce Task 
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2-8 Reduce Task 执 行 过 程 


2.5 Hadoop MapReduce 作 业 的 生命 周期 














由 于 本 书 以 “作业 生命 周期 "为 线索 对 Hadoop MapReduce 架 构 设 计 和 实现 原理 进行 解析 ， 因 而 在 深入 剖析 各 个 MapReduce 实 现 细节 之 前 
整体 了 解 一 个 作业 的 生命 周期 显得 非常 重要 。 为 此 ， 本 节 主 要 讲解 Hadoop MapReduce 作 业 的 生命 周期 ， 即 作业 从 提交 到 运行 结束 经 历 的 
整个 过 程 。 本 节 只 是 概要 性 地 介绍 MapReduce 作 业 的 生命 周期 ， 可 看 作 后 续 几 章 的 内 容 导 读 。 作 业 生 命 周期 中 具体 各 个 阶段 的 深入 剖析 

将 在 后 续 的 章节 中 进行 。 
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假设 用 户 编写 了 一 个 MapReduce 程 序 ， 并 将 其 打包 成 xxx.jar 文 件 ， 然 后 使 用 以 下 命令 提交 作业 : 














SHADOOP_HOME/bin/hadoop jar xxx.jar\ 
-D mapred.job.name="xxx"\ 

-D mapred.map.tasks=3\ 

-D mapred.reduce.tasks=2\ 

-D input=/test/input\ 

-D output=/test/output 











则 该 作业 的 运行 过 程 如 图 2-9 所 示 。 















作业 /任务 进度 监控 
ja 作业 /任务 调度 
TaskTrackerTask#¢4it 
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bin/hadoop jar xxx.jar ... 
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2-9 Hadoop MapReduce 作 业 的 生命 周期 


这 个 过 程 分 为 以 下 5 个 步骤 : 








步骤 1 作业 提交 与 初始 化 。 用 户 提交 作业 后 ， 首 先 由 JobClent 实 例 将 作业 相关 信息 ， 比 如 将 程序 jar 包 、 作 业 配 置 文件 、 分 片 元 信息 
文件 等 上 传 到 分 布 式 文件 系统 一 般 为 HDFS， 上 ， 其 中 ， 分 片 元 信息 文件 记录 了 每 个 输入 分 片 的 逻辑 位 置信 息 。 然 后 JobClienmt 通 过 RPC 
通知 JobTracker。JobTracker 收 到 新 作业 提交 请 求 后 ， 由 作业 调度 模块 对 作业 进行 初始 化 ， 为 作业 创建 一 个 JobInProgress 对 象 以 跟踪 作业 运 
行 状 况 ， 而 JobInProgress 则 会 为 每 个 Task 创 建 一 个 TaskInProgress 对 象 以 跟踪 每 个 任务 的 运行 状态 ，TaskInProgress 可 能 需要 管理 多 个 “Task 运 













































































行 尝试 ”( 称 为 “Task Attempt”) 。 具 体 分 析 见 第 5 章 。 















































步骤 2 ”任务 调度 与 监控 。 前 面 提 到 ， 任 务 调度 和 监控 的 功能 均 由 JobTracker 完 成 。TaskTracker 周 期 性 地 通过 Heartbeat 向 JobTracker 汇 
报 本 节点 的 资源 使 用 情况 ， 一 旦 出 现 空闲 资源 ，JobTracker 会 按照 一 定 的 策略 选择 一 个 合适 的 任务 使 用 该 空闲 资源 ， 这 由 任务 调度 器 完 
成 。 任 务 调度 器 是 一 个 可 插 拔 的 独立 模块 ， 且 为 双 层 架构 ， 即 首先 选择 作业 ， 然 后 从 该 作业 中 选择 任务 ， 其 中 ， 选 择 任 务 时 需要 重点 考 
虑 数据 本 地 性 。 此 外 ，JobTracker 跟 踪 作 业 的 整个 运行 过 程 ， 并 为 作业 的 成 功 运行 提供 全 方位 的 保障 。 首 先 ， 当 TaskTracker 或 者 Task 失 败 
时 ， 转 移 计 算 任 务 ， 其 次 ， 当 某 个 Task 执 行进 度 远 落 后 于 同一 作业 的 其 他 Task 时 ， 为 之 启动 一 个 相同 Task， 并 选取 计算 快 的 Task 结 果 作为 


最 终结 果 。 具 体 分 析 见 第 6 章 。 










































































































































































































































































步骤 3 任务 运行 环境 准备 。 运 行 环境 准备 包括 JVM 启 动 和 资源 隔离 ， 均 由 TaskTracker 实 现 。TaskTracker 为 每 个 Task 启 动 一 个 独立 的 
JVM 以 避免 不 同 Task 在 运行 过 程 中 相互 影响 ， 同 时 ，TaskTracker 使 用 了 操作 系统 进程 实现 资源 隔离 以 防止 Task 滥 用 资源 。 有 具体 分 析 见 第 7 












































































































































步骤 4 ”任务 执行 。TaskTracker 为 Task 准 备 好 运行 环境 后 ， 便 会 启动 Tassk。 在 运行 过 程 中 ， 每 个 Task 的 最 新 进度 首先 由 Task 通 过 RPC 
汇报 给 TaskTracker， 再 由 TaskTracker 汇 报 给 JobTracker。 上 有 具体 分 析 见 第 8 章 。 





















































DUES 作业 完成 。 待 所 有 Task 执 行 完毕 后 ， 整 个 作业 执行 成 功 。 


2.6 ”小结 


























Hadoop MapReduce 直 接 诞 生 于 搜索 领域 ， 以 易于 编程 、 良 好 的 扩展 性 和 高 容错 性 为 设计 目标 。 它 主要 由 两 部 分 组 成 : 编程 
模型 和 运行 时 环境 。 其 中 ， 编 程 模型 为 用 户 提 供 了 5 个 可 编程 组 件 ， 分 别 是 InputFormat、Mapper、Partitioner、Reducer 和 
OutputFormat; 运行 时 环境 则 将 用 户 的 MapReduce 程 序 部 署 到 集群 的 各 个 节点 上 ， 并 通过 各 种 机 制 保证 其 成 功 运行 。 




































































































































































Hadoop MapReduce 处 理 的 数据 一 般 位 于 底层 分 布 式 文件 系统 中 。 该 系统 往往 将 用 户 的 文件 切 分 成 若干 个 固定 大 小 的 block 存 
储 到 不 同 节 点 上 。 默 认 情况 下 ，MapReduce 的 每 个 Task 处 理 一 个 block。MapReduce 主 要 由 四 个 组 件 构成 ， 分 别 是 Client、 
JobTracker、TaskTracker 和 Task， 它 们 共同 保障 一 个 作业 的 成 功 运行 。 一 个 MapReduce 作 业 的 运行 周期 是 ， 先 在 Clent 端 被 提交 到 
JobTracker 上 ， 然 后 由 JobTracker 将 作业 分 解 成 若干 个 Task， 并 对 这 些 Task 进 行 调 度 和 监控 ， 以 保障 这 些 程序 运行 成 功 ， 而 
TaskTracker 则 启动 JobTracker 发 来 的 Task， 并 向 JobTracker 汇 报 这 些 Task 的 运行 状态 和 本 节点 上 资源 的 使 用 情况 。 



































































































































第 二 部 分 
本 部 分 内 容 
MapReduce 编 程 模型 
第 3 章 ”MapReduce 编 程 模 型 
MapReduce 应 用 广泛 的 原因 之 一 在 于 它 的 易 用 性 。 
们 已 经 对 该 编程 模型 的 定义 以 及 应 用 场景 做 了 简单 介绍 











深入 分 析 ， 包 括 其 


























MapReduce 编 程 模型 篇 


它 提供 了 一 个 因 高 度 抽象 化 而 变 得 异常 简单 的 编程 模型 1。 在 第 2 章 中 ， 






































有 程 模型 的 体系 结构 、 设 计 原 理 等 。 
































本 章 不 介绍 Hadoop MapReduce API 的 使 用 方法 ， 而 是 从 实现 角度 介绍 其 设计 方法 。 


3.1 ”MapReduce 编 程 模 型 概述 






































1) 34 (iteration〉。 








在 第 2 章 中 ， 我 们 提 到 MapReduce 是 在 总 结 大 量 应 






























































遍历 输入 数据 ， 并 将 之 解析 成 keyvalue 对 。 


2) 将 输入 keyvalue 对 映射 (map) 成 另外 一 些 keyvalue 对 。 


3) 依据 key 对 中 间 数 据 进行 分 组 (grouping) 。 





























4) 以 组 为 单位 对 数据 进行 归 约 (reduce)〉。 





5) 迭代 。 将 最 终 
MapReduce 将 计算 过 程 


为 了 实现 MapReduce 多 章程 模型 ， 


























分 解 成 以 上 5 个 步 又 六 


Hadoop 设 计 了 











产生 的 keyvalue 对 保存 到 输出 文件 中 。 





3.1.1 MapReduce 编 程 接口 体系 结构 


MapReduce 编 程 模型 对 外 提供 





Nil 





分 为 两 层 。 第 一 



























































。Hadoop 自 带 了 很 多 直接 可 用 的 InputFormat、Partitioner 和 OutputFormat， 大 部 分 情况 下 ， 
































层 是 工具 层 ， 位 于 基本 Java API 之 上 ， 








台 的 兼容 性 而 提出 来 的 。 在 该 层 中 ， 








H a 














一 系列 对 外 编程 接 


带 来 的 最 大 好 处 是 组 件 化 与 并 行 化 。 
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j 的 共同 特点 的 基础 上 抽象 出 来 的 分 布 式 计算 框架 ， 它 适用 的 应 用 场景 往往 
kt 有 一 个 共同 的 特点 : 任务 可 被 分 解 成 相互 独立 的 子 问题 。 基 于 该 特点 ，MapReduce 编 程 模型 给 出 了 其 分 布 式 编程 方法 ， 共 分 5 个 









































EI 














。 用 户 可 通过 实现 这 些 接口 完成 应 用 程序 的 开发 。 






































的 编程 接口 体系 结构 如 图 3-1 所 示 ， 整 个 编程 模型 位 于 应 


是 最 基本 的 Java API， 主 要 有 5 个 可 编程 组 伯 






















































































主要 是 为 了 方便 用 户 编写 复杂 的 MapReduce 程 序 和 利 月 























主要 提供 了 4 个 编 














程 工具 包 。 























其 他 编程 语言 增加 MapReduce 计 算 了 


。 在 这 一 章 中 ， 我 们 将 从 Hadoop MapReduce 编 程 模型 实现 的 角度 对 其 进行 





程序 层 和 MapReduce 执 行 器 之 间 ， 可 以 
FE， 分 别 是 InputFormat、Mapper、Partitioner、Reducer 和 OutputFormat 
用 户 只 需 编写 Mapper 和 Reducer 妈 可。 第 二 


区 


用 户 程序 用 户 应 用 程序 


编程 接口 层 


( Java ) 


作业 


ChainMapper 
ChainReducer 
(Chained mappers ) 


JobControl 
(DAG ) 


Hadoop Streaming Hadoop Pipes 


工具 层 (Python,PHP... APD (C++ API) 


Partitioner OutputFormat 


MapReduce Runtime 











图 3-1 MapReduce 编 程 接口 体系 结构 








QJobControl: 方便 用 户 编写 有 依赖 关系 的 作业 ， 这 些 作 业 往 往 构成 一 个 有 向 图 ， 所 以 通常 称 为 DAG (Directed Acyclic Graph) 
， 如 第 2 章 中 的 朴素 贝 叶 斯 分 类 算法 实现 便 是 4 个 有 依赖 关系 的 作业 构成 的 DAG。 





























口 ChainMapper/ChainReducer: 方便 用 户 编写 链 式 作业 ， 即 在 Map 或 者 Reduce 阶 段 存在 多 个 Mapper， 形 式 如 下 : 
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[APPER+REDUCER MAPPER* 
































Q Hadoop Streaming: 方便 用 户 采 用 非 Java 语 言 编 写作 业 ， 人 允许 用 户 指定 可 执行 文件 或 者 脚本 作为 Mapper/Reducer。 























口 Hadoop Pipes: 专门 为 CC++ 程 序 员 编 号 MapReduce 程 序 提供 的 工具 包 。 

















[1] 关于 MapReduce 编 程 模型 的 数学 基础 ， 可 参考 RalffLammel 的 论文 “Google’s MapReduce Programming Model—Revisited”. 
[2] 还 有 一 个 组 件 是 Combiner， 它 实际 是 一 个 Reducer。 








ROW, EH ARE 


中 的 每 一 个 方法 。 接 


3.1.2 ”新 旧 MapReduce API 比 较 














从 0.20.0 版 本 开始 ，Hadoop 同 时 提供 了 新 旧 两 套 MapReduce API。 新 API 在 旧 API 基 础 上 进行 了 封装 ， 使 得 其 在 扩展 性 和 易 用 
性 方面 更 好 。 新 旧版 MapReduce API 的 主要 区 别 如 下 。 


































































































(1) 存放 位 置 




















版 API 放 在 org.apache.hadoop.mapred 包 中 ， 而 新 版 API 则 放 在 org.apache.hadoop.mapreduce 包 及 














HP ALE 





(2) 接口 变 为 抽象 类 












































接口 通常 作为 一 种 严格 的 "协议 约束 ” 它 只 有 方法 声明 而 





没有 方法 实现 ， 且 要 求 所 有 实现 类 《不 包括 抽象 类 ) 必须 实现 接口 
， 进 而 实现 类 似 C++ 中 的 "多重 继 承 ” 抽象 类 则 是 一 种 较 宽 松 


提供 默认 实现 。 而 继承 类 则 可 选择 是 否 重 新 实现 这 些 方法 。 正 是 因为 这 一 点 ， 抽 象 类 在 类 衍化 方 














口 的 最 大 优点 是 允许 一 个 类 实现 多 个 接 




















的 “的 






































































































































机 更 
有 优势 ， 也 就 是 说 ， 抽 象 类 具有 良好 的 向 后 兼容 性 ， 当 需要 为 抽象 类 添加 新 的 方法 时 ， 只 要 新 添加 的 方法 提供 了 默认 实现 ， 用 户 
之 前 的 代码 就 不 必修 改 了 。 


后 变 短 ， 使 得 函数 更 容易 使 用 ;， 划 


改 ， 这 样 保证 了 向 后 兼容 性 ， 具 有 良好 的 扩展 性 


函数 ) , H 


作 























考虑 到 抽象 类 在 API 衍 化 方 














再 的 优势 ， 新 API 将 InputFormat、OutputFormat、Mapper、Reducer 和 PartitionerI 





























接口 变 为 抽象 类 。 
(3) 上 下 文 封装 


新 版 API 将 变量 和 函数 封装 成 各 种 上 下 文 《Context) 类 ， 使 得 API 具 有 更 好 的 易 用 性 和 扩展 性 。 首 先 ， 函 数 参 数列 表 经 封装 


次 ， 当 需要 修改 或 添加 某 些 变 量 或 函数 时 ， 只 需 修 改 封装 后 的 上 下 文 类 即 可 ， 月 

































































日 户 代 码 无 须 修 















































图 3-2 展 示 了 新 版 API 中 树 形 的 Context 类 继承 关系 。 这 些 Context 各 








自封 装 了 一 种 实体 的 基本 信息 及 对 应 的 操作 (setter 和 getter 
上 JobContext、TaskAttemptContext 分 别 封装 了 Job 和 Task 的 基本 信息 ，TaskInputOutputContext 封 装 了 Task 的 各 种 输入 输出 操 


，MapContext 和 ReduceContext 分 别 封装 了 Mapper 和 Reducer 对 外 的 公共 接口 。 






MapContext 








JobContext TaskAttemptContext 





TaskInputOutputContext 


ReduceContext 

















图 3-2 新 版 API 中 树 形 Context 类 继承 关系 


























除了 以 上 三 点 不 同 之 外 ， 新 旧 API 在 很 多 其 他 细节 方 盏 









































bp 存 在 小 的 差别 ， 具 体 将 在 接 下 来 的 内 容 中 讲解 。 





















































由 于 新 版 和 旧版 API 在 类 层次 结构 、 编 程 接口 名 称 及 对 应 的 参数 列表 等 方面 存在 较 大 差别 ， 所 以 两 种 API 不 能 



































到 应 用 程序 的 向 后 兼容 性 ， 短 时 间 内 不 会 将 旧 API 从 MapReduced 
仅 将 旧 API 标 注 为 过 期 


版 API 的 设计 思路 ， 而 对 于 新 版 API， 仅 是 概要 介绍 它 与 














RA. (ABE 
hb 去掉。 即使 在 完全 采用 新 API 的 0.21.0/0.22.X 版 本 系列 中 ， 也 仅 

























































































(deprecated) ， 用 户 仍然 可 以 使 用 。 




















本 章 将 对 比 介绍 两 套 MapReduce API 的 设计 细节 。 但 








考虑 到 新 版 API 只 是 在 旧版 基础 上 封装 而 来 的 ， 医 
版 本 的 不 同 之 处 。 

















此 ， 我 们 将 详细 分 析 


























3.2 MapReduce API 基 本 概念 
































在 正式 分 析 新 旧 API 之 前 ， 先 要 介绍 几 个 基本 概念 。 这 些 概 念 贯穿 于 所 有 API 之 中 














>H 








此 ， 有 必要 单独 讲解 。 














3.2.1 序列 化 

















序列 化 是 指 将 结构 化 对 象 转 为 字 节 流 以 便于 通过 网 络 进 行 传输 或 写 入 持久 存储 的 过 程 。 反 序列 化 指 的 是 将 字 节 流转 为 结构 化 
对 象 的 过 程 。 在 Hadoop MapReduce 中 ， 序 列 化 的 主要 作用 有 两 个 : 永久 存储 和 进程 间 通 信 。 



























































为 了 能 够 读 取 或 者 存储 Java 对 象 ，MapReduce 编 程 模型 要 求 用 户 输入 和 输出 数据 中 的 key 和 value 必 须 是 可 序列 化 的 。 在 Hadoop 
MapReduce 中 ， 使 一 个 Java 对 象 可 序列 化 的 方法 是 让 其 对 应 的 类 实现 Writable 接 口 。 但 对 于 key 而 言 ， 由 于 它 是 数据 排序 的 关键 字 ， 










































































寻 此 还 需要 提供 比较 两 个 key 对 象 的 方法 。 为 此 ，key 对 应 类 需 实现 WritableComparable 接 口 ， 它 的 类 如 图 3-3 所 示 l. 


<<interface>> - 

java. C [o 
+write(in out : DataOutput) Jarn = Sam am samit : 
+readFields(in in : DataInput) +compareTo(in object : Object) : int 










<<interface> 
WritableComparable<T> 


3-3 ”序列 化 接口 WritableComparablke 的 类 
[1] 关于 Hadoop 序 列 化 的 更 详细 介绍 ， 可 参考 《Hadoop 权 威 指南 》 的 “第 4 章 Hadoop I/O”. 
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3.2.2 Reporter 参数 


Reporter 是 MapReduce 提 供给 应 用 程序 的 工具 。 如 图 











设 定 状 态 消 








Reporter 是 一 个 基础 参数 。MapReduce 对 外 提供 的 大 部 分 组 件 ， 包 括 InputFormat、Mapper 和 Reducer 等 ， 均 厂 


了 该 参数 ， 有 具体 可 参考 3.3 记 。 














息 〈setStatus) 以 及 更 新 计数 器 CincrCounter) 。 























3-4 所 示 ， 应 用 程序 可 使 月 









<<interface>> 
Progressable 


+progress () 


<<interface>> 
Reporter 
+setStatus (in status) 
+getCounter(in name : Enum<?>) : Counter 


+getCounter(in group, in name) : Counter 
tincrCounter (in key : Enum<?>, in amount : long) 


+incrCounter (in group, in counter, in amount) 
+getInputSplit () : InputSplit 





A] 3-4 Reporter 的 类 图 





月 Reporter 中 的 方法 报告 完成 进度 〈progress) ~ 











E 其 主要 方法 中 添加 


3.2.3 ”回调 机 制 












































可 调 机 制 是 一 种 常见 的 设计 模式 。 它 将 工作 流 内 的 某 个 功能 按照 约定 的 接口 暴露 给 外 部 使 用 者 ， 为 外 部 使 用 者 提供 数据 ， 或 要 求 
外 部 使 用 者 提供 数据 。 















































Hadoop MapReduce 对 外 提供 的 $ 个 组 件 〈InputFormat、Mapper、Partitioner、Reducer 和 OutputFormat) 实际 上 全 部 属于 回调 接口 。 当 
用 户 按照 约定 实现 这 几 个 接口 后 ，MapReduce 运 行 时 环境 会 自动 调用 它们 。 











































































































如 图 3-5 所 示 ，MapReduce 给 用 户 暴露 了 接口 Mapper， 当 用 户 按 照 自 己 的 应 用 程序 逻辑 实现 自己 的 MyMapper 后 ，Hadoop 
MapReduce 运 行 时 环境 会 将 输入 数据 解析 成 key/value 对 ， 并 调用 map0 函 数 迭 代 处 理 。 





























Hadoop 应 用 程序 Hadoop MapReduce RunTime 
Map Task 





【Map Task 初 始 化 】 
this .mapper = 
ReflectionUtils.newInstance(job.getMapperClass(), job); 


public class MyJob { / 睦 他 初始 化 工作 


public static class MyMapper implements 
Mapper<K, V, K, V> { 
public void map(K key, V val, 
OutputCollector<K, V> output, 【和 迭代 处 理 数 据 】 
Reporter reporteD { /从 输入 数据 中 解析 出 key, value> 
output.collect(key, val); while (input next(key, value)) { 
4 调用 用 户 编 写 的 Mapper 
mapper.map(key, value, output, reporter); 


JobConf job = new JobConf(new Configuration(), er 
MyJob.class); 
job.setMapperClass( MyJob .MyMapper .class); 
/其 他 配置 


[Map Task 运行 结束 】 





图 3-5 MapReduce 回 调 机 制 实例 








3.3 Java API 解析 


节 将 对 比 讲解 这 


3:3 


XMLAK IRH. i 














Hadoop 的 主要 编程 语言 是 Java， 因 而 Java API 是 最 基本 的 对 外 编程 接口 。 当 前 各 个 版 本 的 Hadoop 均 同时 存在 新 旧 两 种 API。 本 



























































种 API 的 设计 思路 ， 主 要 内 容 包 括 使 用 实例 、 接 口 设计 、 在 MapReduce 运 行 时 环境 中 的 调用 时 机 等 。 





.1 作业 配置 与 提交 


1.Hadoop 配 置 文件 介绍 

















在 Hadoop 中 ，Common、HDFS 和 MapReduce 各 有 对 应 的 配置 文件 ， 用 于 保存 对 应 模块 中 可 配置 的 参数 。 这 些 配置 文件 均 为 



































部 分 构成 : 系统 默认 配置 文件 和 管理 员 自 定义 配置 文件 。 其 中 ， 系 统 默认 配置 文件 分 别 是 core-defaultxml、hdfS- 



































defaultxml 和 mapred-deBultxml， 它 们 包含 了 所 有 可 配置 属性 的 默认 值 。 而 管理 员 自 定 义 配 置 文件 分 别 是 core-site.xml、hdf-site.xml 和 
mapred-site.xml。 它 们 由 管理 员 设 置 ， 主 要 用 于 定义 一 些 新 的 配置 属性 或 者 覆盖 系统 默认 配置 文件 中 的 默认 值 。 通 常 这 些 配置 一 














AA 

















中 ， 
性 : 





置 文 伯 





在 Hadoop 中 ， 每 个 配置 属性 了 
属性 描述 仅仅 用 来 帮助 用 户 理解 属性 的 含义 ，Hadoop 内 部 并 不 会 使 用 它 的 值 。 此 外 ，Hadoop 为 配置 文件 添加 了 两 个 新 的 特 













































































定 ， 便 不 能 被 修改 〈 如 果 想 修改 ， 需 重新 启动 Hadoop) 。 需 要 注意 的 是 ，core-defaultxml 和 core-site.xml 属 于 公共 基础 库 的 配 
F， 默 认 情 况 下 ，Hadoop 总 会 优先 加 载 它们 。 























上 

















要 包括 三 个 配置 参数 ，name、value 和 description， 分 别 表示 属性 名 、 属 性 值 和 属性 描述 。 其 































































































final 参 数 和 变量 扩展 。 


















































口 final 参 数 : 如 果 管 理 员 不 想 让 用 户 程序 修改 某 些 属性 的 属性 值 ， 可 将 该 属性 的 fnal 参 数 置 为 tue， 比 如 : 






































<property> 
<name>mapred.map.tasks.speculative.execution</name> 
<value>true</value> 

<final>true</final> 

</property> 























管理 员 一 般 在 XXX-site.xm 配 置 文件 中 为 某 些 属性 添加 fnal 参 数 ， 以 防止 用 户 在 应 用 程序 中 修改 这 些 属 性 的 属性 值 。 






































口 变 量 扩展 : 当 读 取 配 置 文件 时 ， 如 果 某 个 属性 存在 对 其 他 属性 的 引用 ， 则 Hadoop 首 先 会 查找 引用 的 属性 是 否 为 下 列 两 种 














〇 其 他 已 经 





定义 的 属性 。 


























性 之 一 。 如 果 是 ， 则 进行 扩展 。 











OJava 中 System getProperties0 函 数 可 获取 属性 。 





比如 ， 如 果 一 个 配置 文件 中 包含 以 下 配置 参数 : 


AN 














<property> 


<name>hadoop.tmp.dir</name> 
<value>/tmp/hadoop-${user.name}</value> 
</property> 


<property> 


<name>mapred.temp.dir</name> 
<value>${hadoop.tmp.dir}/mapred/temp</value> 
</property> 























则 当 用 户 想 








H 

















获取 属性 mapred.temp.dir 的 值 时 ，Hadoop 会 将 hadoop.tmp.dir 解 析 成 该 配置 文件 中 另外 一 个 属性 的 





it 


， 而 user.name 


























则 被 蔡 换 成 系统 属性 username 的 值 。 


2.MapReduce 作 业 配 置 与 提交 


分 。 环 境 配置 























在 MapReduce 中 ， 每 个 作业 由 两 部 分 组 成 : 应 用 程序 和 作业 配置 。 其 中 ， 作 业 配 置 内 容 包括 环境 配置 和 用 户 自 定 义 配置 两 部 
















































































Hadoop 自 动 添加 ， 主 要 由 mapred-defaultxml 和 mapred-site.xml 两 个 文件 中 的 配置 选项 组 合 而 成 ， 用 户 自 定 义 配置 则 





























am 




















j 户 自己 根据 作业 特点 个 性 化 定制 而 成 ， 比 如 用 户 可 设置 作业 名 称 ， 以 及 Mapper/Reducer、Reduce Task 个 数 等 。 在 新 旧 两 套 
中 ， 作 业 配 置 接口 发 生 了 变化 ， 首 先 通 过 一 个 例子 感受 一 下 使 用 上 的 不 同 。 











= 


















































API 作 业 配 置 实例 : 





JobConf job=new JobConf (new Configuration(), MyJob.class) ; 
job.setJobName ("myjob") ; 

job.setMapperClass (MyJob.MyMapper.class) ; 
job.setReducerClass (MyJob.MyReducer.class) ; 
JobClient.runJob (job) ; 





新 API 作 业 配 置 实例 : 





Configuration conf=new Configuration(); 

Job job=new Job (conf, "myjob") ; 
job.setJarByClass (MyJob.class) ; 
job.setMapperClass (MyJob.MyMapper.class) ; 
job.setReducerClass (MyJob.MyReducer.class) ; 
System.exit (job.waitForCompletion (true) ?0: 1); 











从 以 上 两 个 实例 可 以 看 出 ， 新 版 API 用 Job 类 代替 了 JobConf 和 JobClient 两 个 类 ， 这 样 ， 仅 使 用 一 个 类 的 同时 可 完成 作业 配置 和 











作业 提交 相关 功能 ， 进 一 步 简化 了 作业 编写 方式 。 我 们 将 在 第 5 章 介绍 作业 提交 的 相关 细节 ， 本 小 节 重 点 从 设计 角度 分 析 新 旧 两 
套 API 中 作业 配置 的 相关 实现 细节 。 











3. 旧 API 中 的 作业 配置 

















MapReduce 配 置 模块 代码 结构 如 图 3-6 所 示 。 其 中 ，org.apache.hadoop.conf 中 的 Configuration 类 是 配置 模块 最 底层 的 类 。 从 图 3-6 











中 可 以 看 出 ， 该 类 支持 以 下 两 种 基本 操作 。 











口 序列 化 : 序列 化 是 将 结构 化 数据 转换 成 字 节 流 ， 以 便于 传输 或 存储 。Java 实 现 了 自己 的 一 套 序列 化 框架 。 几 是 需要 支持 序 











列 化 的 类 ， 均 需要 实现 Wiritable 接 口 。 























Die: 为 了 方便 遍历 所 有 属性 ， 它 实现 了 Java 开 发 包 中 的 Iterator 接 


<<interface> 
java.util Iterator +write(in out : DataOutput) 


+readFields(in in : Datalnput) 
人 
































+getT YPE(in name : String, in default: TYPE) : TYPE 
+setT YPHin name : String, in value : TYPE) 






JobConf 


+getAttribute() : ATTRIBUTE 


+setAttribute(in attribute : ATTRIBUTE) 





X 











3-6 |HMapReduce API 中 作业 配置 类 


Configuration 类 总 会 依次 加 载 core-defaultxml 和 core-site.xml 两 个 基础 配置 文件 ， 相 关 代 码 如 下 : 








addDefaultResource ("core-default.xml") ; 
addDefaultResource ("core-site.xml") ; 





addDefauttResource 函 数 的 参数 为 XML 文件 名 ， 它 能 够 将 XML 文件 中 的 name/value 加 载 到 内 存 中 。 
对 于 同一 个 配置 选项 ， 其 后 面 的 值 会 覆盖 前 面 的 值 。 





LE 


连续 调用 多 次 该 函数 时 ， 




















mt 















































Configuration 类 中 有 大 量 针 对 常见 数据 类 型 的 getter/setter 函 数 ， 用 于 获取 或 者 设置 某 种 数据 类 型 属性 的 属性 值 。 比 如 ， 对 于 
float 类 型 , 提供 nf 这 样 一 对 函数 : 









































float getFloat (String name, float defaultValue) 
void setFloat (String name, float value) 








除了 大 量 getter/setter 函 数 外 ，Configuration 类 中 还 有 一 个 非常 


bk 
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void writeXml (OutputStream out) 














该 函数 能 够 将 当前 Configuration 对 象 中 所 有 属性 及 属性 值 保存 到 一 个 XML 文 件 中 ， 以 便于 在 节点 之 间 传 输 。 这 点 在 以 后 的 几 














JobCon 伙 描述 了 一 个 MapReduce 作 业 运 行 时 需要 的 所 有 信息 ， 而 MapReduce 运 行 时 环境 正 是 根据 JobCon 人 得 供 的 信息 运行 作业 
的 。 





JobConf 继 承 了 Configuration 类 ， 并 添加 了 一 些 设置 /获取 作业 属性 的 settergetter 函 数 ， 以 方便 用 户 编写 MapReduce 程 序 ， 如 设置 / 
获取 Reduce Task 个 数 的 函数 为 : 











public int getNumReduceTasks() {return getInt ("mapred.reduce.tasks", 1); } 
public void setNumReduceTasks (int n) {setInt ("mapred.reduce.tasks", n); } 




















JobConf 中 添加 的 函数 均 是 对 Configuration 类 中 函数 的 再 次 封装 。 由 于 它 在 这 些 函 数 名 中 融入 了 作业 属性 的 名 字 ， 因 而 更 易于 









































默认 情况 下 ，JobConf 会 自动 加 载 配置 文 件 mapred-default.xml 和 mapred-site.xml， 相 关 代 码 如 下 : 








static{ 
Configuration.addDefaultResource ("mapred-default.xml") ; 
Configuration.addDefaultResource ("mapred-site.xml") ; 


} 





4. 新 API 中 的 作业 配置 



































前 面 提 到 ， 与 新 API 中 的 作业 配置 相关 的 类 是 Job。 该 类 同时 具有 作业 配置 和 作业 提交 的 功能 ， 其 中 ， 作 业 提 交 将 在 第 $ 章 中 
介绍 ， 这 里 只 关注 作业 配置 部 分 。 作 业 配 置 部 分 的 类 图 如 图 3-7 所 示 。Job 类 继承 了 一 个 新 类 JobContext， 而 Context 自 身 则 包含 一 
个 JobCon 赤 型 的 成 员 。 注 意 ，JobContext 类 仅 提 供 了 一 些 getter 方 法 ， 而 Job 类 中 则 提供 了 一 些 setter 方 法 。 















































































-conf : org.apache.hadoop.mapred.JobConf 
+getAttribute() : ATTRIBUTE 
ZX 
+setAttribute(in attribute : ATTRIBUT 


3-7 ”新 MapReduce API 中 作业 配置 类 图 
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3.3.2 ”InputFormat 接 口 的 设计 与 实现 
































InputFormat 主 要 用 于 描述 输入 数据 的 格式 ， 它 提供 以 下 两 个 功能 。 














口 数据 切 分 : 按照 某 个 策略 将 输入 数据 切 分 成 若干 个 spjt， 以 便 确 定 Map Task 个 数 以 及 对 应 的 splt。 














口 为 Mapper 提 供 输入 数据 : 给 定 某 个 sptt， 能 将 其 解析 成 一 个 个 key/value 对 。 














本 小 节 将 介绍 Hadoop 如 何 设计 InputFormat 接 口 ， 以 及 提供 了 哪些 常用 的 InputFormat 实 现 。 








1. 旧 版 API 的 InputFormat 解 析 


如 图 3-8 所 示 ， 在 旧版 API 中 ，InputFormat 是 一 个 接口 ， 它 包含 两 种 方法 : 





InputSplit[]getSplits (JobConf job, int numSplits) throws IOException; 
RecordReader<K, V>getRecordReader (InputSplit split, 

JobConf job, 

Reporter reporter) throws IOException; 














gtSplts 方 法 主要 完成 数据 切 分 的 功能 ， 它 会 尝试 着 将 输入 数据 切 分 成 namSplits 个 InputSplt。InputSplit 有 以 下 两 个 特点 。 






































Oats}: 它 只 是 在 逻辑 上 对 输入 数据 进行 分 片 ， 并 不 会 在 磁盘 上 将 其 切 分 成 分 片 进行 存储 。InputSplt 只 记录 了 分 片 的 元 数据 信 
息 ， 比 如 起 始 位 置 、 长 度 以 及 所 在 的 节点 列表 等 。 

































































口 可 序列 化 : 在 Hadoop 中 ， 对 象 序列 化 主要 有 两 个 作用 : 进程 间 通 信和 永久 存储 。 此 处 ，InputSpkt 支 持 序 列 化 操作 主要 是 为 了 进程 间 
通信 。 作 业 被 提交 到 JobTracker 之 前 ，Clent 会 调用 作业 InputFormat 中 的 getSplts 函 数 ， 并 将 得 到 的 InputSplt 序 列 化 到 文件 中 。 这 样 ， 当 作业 
提交 到 JobTracker 端 对 作业 初始 化 时 ， 可 直接 读 取 访 文件， 解析 出 所 有 InputSpit， 并 创建 对 应 的 Map Task. 

































































+getSplits (in job : JobConf, in numSplits : int) : InputSplit [] 
+getRecordReader(in split : InputSplit, in job : JobConf, in report : Reporter) : RecordReader<K, V> 


<<interface> 
InputSplit 

tnext(in key : K, in value : V) : boolean be petLength Qn A 
aea a ck +getLocations() : String [] 
+createValue() : V 
+getPos() : long 
+close() 
tgetProgress() : float 























图 3-8 旧 API 中 InputFormat 关 图 











坚 丰 ecordReader 方 法 返回 一 个 RecordReader 对 象 ， 该 对 象 可 将 输入 的 InputSptt 解 析 成 若干 个 keyvalue 对 。MapReduce 框 架 在 Map Task 执 
行 过 程 中 ， 会 不 断 调 用 RecordReader 对 象 中 的 方法 ， 和 途 代 获取 keyvalue 对 并 交 给 map0 函 数 处 理 ， 主 要 代码 〈 经 过 简化 ) 如 下 : 














Jy 



































// 调 用 InputSplit 的 getRecordReader 方 法 获取 RecordReader<K1, V1>input 
Kl key=input.createKey (); 

V1 value=input.createValue(); 
while (input.next (key, value) ) { 


// 调 用 用 户 编写 的 map () 函数 





























input.close(); 






































前 面 分 析 了 InputFormat 接 口 的 定义 ， 接 下 来 介绍 系统 自 带 的 各 种 InputFormat 实 现 。 为 了 方便 用 户 编写 MapReduce 程 序 ，Hadoop 自 带 了 
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一 些 针 对 数据 库 和 文件 的 mputFormat 实 现 ， 有 具体 如 图 3-9 所 示 。 通 常 而 言 ， 用 户 需要 处 理 的 数据 均 以 文件 形式 存储 到 HDFS 上 ， 所 以 我 们 习 
点 针对 文件 的 InputFormat 实 现 进 行 讨论 。 
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DBInputFormat FileInputFormat EmptyInputFormat 
EN 








ombineFileInputFormat| |NLineInputFormat| |SequenceFileInputFormat| 区 eyValueTextInputFormat| |TextInputFormat 








SequenceFileAsBinaryInputFormat SequenceFileAsTextInputFormat SequenceFileInputFilter 











3-9 Hadoop MapReduce 自 带 InputFormat 实 现 的 类 层次 图 





















































如 图 3-9 所 示 ， 所 有 基于 文件 的 InputFormat 实 现 的 基 类 是 FileInputFormat， 并 由 此 派生 出 针对 文本 文件 格式 的 TextInputFormat、 
KeyValueTextInputFormat 和 NLineInputFormat， 针 对 二 进 制 文件 格式 的 SequenceFieInputFormat 等 。 整 个 基于 文件 的 InputFormat 体 系 的 设计 思路 
是 ， 由 公共 基 类 FileInputFormat 采 用 统一 的 方法 对 各 种 输入 文件 进行 切 分 ， 比 如 按照 某 个 固定 大 小 等 分 ， 而 由 各 个 派生 InputFormat 自 己 提 供 
机 制 将 进一步 解析 InputSplt。 对 应 到 具体 的 实现 是 ， 基 类 FileInputFormat 提 供 getSplits 实 现 ， 而 派生 类 提供 getRecordReader 实 现 。 
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为 了 帮助 读者 深入 理解 这 些 InputFormat 的 实现 原理 ， 我 们 选取 TextInputFormat 与 SequenceFileInputFormat 进 行 重点 介绍 。 






































我 们 首先 介绍 基 类 FileInputFormat 的 实现 。 它 最 重要 的 功能 是 为 各 种 InputFormat 提 供 统一 的 getSplits 函 数 。 该 函数 实现 中 最 核心 的 两 个 
算法 是 文件 切 分 算法 和 host 选 择 算法 。(1) 文件 切 分 算法 文件 切 分 算法 主要 用 于 确定 InputSplt 的 个 数 以 及 每 个 InputSplit 对 应 的 数据 段 。 
FileInputFormat 以 文件 为 单位 切 分 生成 InputSplit。 对 于 每 个 文件 ， 由 以 下 三 个 属性 值 确定 其 对 应 的 InputSpkt 的 个 数 。 
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口 goalSize: 它 是 根据 用 户 期 望 的 InputSplit 数 目 计 算出 来 的 ， 即 totalSizemnumSplits。 其 中 ，totalSize 为 文件 总 大 小 ;numSplts 为 用 户 设 定 的 
Map Task 个 数 ， 默 认 情况 下 是 1。 





























DminSize: InputSptt 的 最 小 值 ， 由 配置 参数 mapred.min.splt.size 确 定 ， 默 认 是 1。 





























OblockSize: 文件 在 HDFS 中 存储 的 block 大 小 ， 不 同文 件 可 能 不 同 ， 默 认 是 64 MB。 这 三 个 参数 共同 决定 InputSpt 的 最 终 大 小 ， 计 算 方 
法 如 下 : 





splitSize=max {minSize, min{goalSize, blockSize} } 




















且 确 定 spltSize 值 后 ，FikeInputFormat 将 文件 依次 切 成 大 小 为 splitSize 的 InputSpit， 最 后 剩 下 不 足 splitSize 的 数据 块 单独 成 为 一 个 
InputSplt. 


























【实例 】 输 入 目录 下 有 三 个 文件 flel1、fle2 和 fle3， 大 小 依次 为 1MB，32 MB 和 250 MB。 若 blockSize 采 用 默认 值 64 MB， 则 不 同 minSize 
和 goalSize 下 ，file3 切 分 结果 如 表 3-1 所 示 (三 种 情况 下 ，fie1 与 fle2 切 分 结果 相同 ， 均 为 1 个 InputSplit〉。 























表 3-1 minSize、goalSize、splitSize 与 InputSplit 对 应 关系 


minSize goalSize splitSize file3 对 应 的 InputSplit 数目 输入 目录 对 应 的 InputSplit 总 数 





1 MB totalSize 64 MB 4 6 
(numSplits=1) 





结合 表 和 公式 可 以 知道 ， 如 果 想 让 InputSplit 尺 寸 大 于 block 尺 寸 ， 则 直接 增 大 配置 参数 mapredmin spltsize 即 可 。 





























(2) host 选 择 算法 











待 mputSplit 切 分 方案 确定 后 ， 


























InputSpkt 的 host 列 表 选 择 策略 直接 影响 到 运行 过 程 








位 组 织 的 ， 一 个 大 文件 对 应 的 block 可 能 
位 于 不 同 节点 上 ， 这 使 得 Hadoop 不 可 能 实现 完全 的 数据 本 地 性 。 
localty 和 data center locality (Hadoop 还 未 实现 该 localiy 级 别 ) 。 在 进行 任务 调度 时 ， 会 依次 考虑 这 3 个 节点 的 Jocalty， 即 优先 让 空闲 资源 处 理 








遍布 整个 Hadoop 集 群 





下 一 步 要 确定 每 个 InputSplt 的 元 数据 
InputSpkt 所 在 的 文件 、 起 始 位 置 、 长 度 以 及 所 在 的 host( 节 点) 列表 。 划 












































本 节点 上 的 数据 ， 如 果 节 点 上 没有 
个 数据 中 心 ) 。 











可 处 理 的 数据 ， 则 处 理 | 




















虽然 InputSpit 对 应 的 block 可 能 位 了 








本 地 性 的 主要 凭证 。 为 此 ，FileInpufFormat 设 计 了 
部 按照 每 个 node 包 含 的 数据 量 对 node 排 序 ， 最 后 取 前 N 个 node 的 host 作 为 InputSpiit 


























器 调度 Task 时 ， 只 


【实例 】 某 个 Hadoop 集 群 的 网 络 拓扑 结构 如 
和 75， 很 容易 计算 ，4 个 Iack 包 含 的 〈 该 InputSplt 的 ) Yc 








到 该 InputSpkt 的 host 列 表 中 。 








多 个 节点 上 ， 但 考虑 到 
择 包含 (该 InputSplt〉 数据 总 量 最 大 的 前 几 个 节点 (Hadoop 限 4 
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简单 








TAH 











图 3-10 所 示 ，HDFSd 
量 分 别 是 175、250、150 和 75。rack29 





个 机 架 上 的 数 





























a 
言 息 


。 这 通常 








四 部 分 组 成 :<file, start, 




















为 此 ，Hadoop 将 数据 本 地 怕 





员 ， 最 差 情况 是 处 理 其 


FP 的 任务 本 地 性 。 第 2 章 介 绍 Hadoop 架 构 时 ， 我 们 提 到 HDFS 上 的 文件 是 以 block 为 单 
， 而 InputSplt 的 划分 算法 可 能 导致 一 个 InputSpit 对 应 多 个 block， 这 些 block 可 能 
按照 代价 划分 成 三 个 等 级 : node locality. rack 












































要 将 Task 调 度 给 位 于 host 列 表 的 节点 ， 就 认为 该 Task 满 足 本 地 性 。 





ROOT 


任务 调度 的 效率 ， 通 常 不 会 把 所 
判 最 多 选择 10 个 ， 多 余 的 会 过 滤 掉 ) ， 以 作为 人 有 
启发 式 算法 : 首先 按照 rack 包 含 
的 host 列 表 ， 这 里 的 N 为 block 台 























ipse, 























length, hosts>, SIIK 


中 ， 前 三 项 很 容易 确定 ， 难 点 在 于 host 列 表 的 选择 方法 。 

















他 机 架 上 的 数据 (但 是 必须 位 于 同一 


节点 加 到 InputSpkt 的 host 列 表 中 ， 而 是 选 





务 调度 时 判断 任务 是 否 具 有 





量 对 rack 进 行 排序 ， 然 后 在 rack 内 

















上 本数。 这 样 ， 当 任务 调度 


hblock 副 本 数 为 3， 某 个 InputSplt 包 含 3 个 block， 大 小 依次 是 100、150 
PF 的 node3 和 node4，rack1 中 的 nodel 将 被 添加 
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rackl 
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nodel node2 


rack2 
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node3 


node4 


rack3 
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node5 


node6 


rack4 
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node7 


nodeg 


ag a4 ala ee 


从 以 上 host 选 择 算法 可 知 ， 当 
从 远程 节点 上 读 取 ， 因 























当 使 用 基 了 


分 析 完 FileInputFormat 实 





提 到 ， 由 派生 类 实 








HU TE 























析 成 一 个 个 keyvalue 对 。 在 具体 实现 时 ，RecordReader 应 考虑 以 下 











口 定 位 记录 边界 : 为 了 能 


InputSplit 
而 可 以 得 出 以 下 结论 : 





图 3-10 











用 人 O 表示 某 个 nputSplit 包 含 的 三 个 block 


一 个 Hadoop 集 群 的 网 络 拓扑 结构 图 





HM getRecordReaderi žr, 1% BOK 


口 

















FFileInputFormat 实 现 InputFormat 时 ， 为 了 提高 Map Task 的 数据 本 地 性 ， 应 











尽量 使 InputSpt 大 小 与 


现 方法 ， 接 下 来 分 析 派 生 类 TextImputFormat 与 Sequence-FieInputFormat 的 实现 。 








尺寸 大 于 block 尺 寸 时 ，Map Task 并 不 能 实现 完全 数据 本 地 性 ， 也 就 是 说 ， 总 有 一 部 分 数据 需要 


block 大 小 相同 。 


一 个 RecordReader 对 象 。 它 实现 了 类 似 于 和 迭代 器 的 功能 ， 将 某 个 InputSplit 解 




















符 ; 对 于 SequenceFileInputFormat， 每 隔 若 干 条 记录 会 添加 




















。 男 外 ， 





整 记录 的 起 始 位 









































于 FileInputFormat 仅 仅 按 照 数 据 量 多 少 对 文件 进行 





识别 一 条 完整 的 记录 ， 记 录 之 间 应 该 添加 一 些 
国定 长 度 的 同步 字符 串 。 
y 








同步 标识 。 对 于 TextInputFormat， 每 两 条 记录 之 间 存 在 换行 








通过 换行 符 或 者 同步 字符 捉 ， 
己 录 和 最 后 一 条 记录 可 能 会 被 





因而 InputSptt 的 第 一 条 





它们 很 容易 定位 到 一 个 完 





从 中 间 切 开 。 为 了 解决 这 种 记录 跨越 InputSpkt 的 读 取 问 题 ，RecordReader 规 定 每 个 InputSplt 的 第 一 条 不 完整 记录 划 给 前 一 个 InputSplt 人 处理 。 











口 解析 keyvalue， 定位 到 一 条 新 的 记录 后 ， 需 将 该 记录 分 解 成 key 和 value 两 部 分 。 对 于 TextInputFormat， 每 一 行 的 内 容 即 为 value， 而 该 
行 在 整个 文件 中 的 偏 移 量 为 key。 对 于 SequenceFileInputFonmat， 每 条 记录 的 格式 为 : 














{record length] [key length] [key] [value] 








其 中 ， 前 两 个 字段 分 别 是 整 条 记录 的 长 度 和 key 的 长 度 ， 均 为 4 字 节 ， 后 两 个 字段 分 别 是 key 和 value 的 内 容 。 知 道 每 条 记录 的 格式 后 ， 
很 容易 解析 出 key 和 value。 


2. 新 版 API 的 InputFormat 解 析 




















新 版 API 的 InputFormat 类 图 如 图 3-11 所 示 。 新 APJI 与 上 昌 API 比 较 ， 在 形式 上 发 生 了 较 大 变化 ， 但 仔细 分 析 ， 发 现 仅仅 是 对 之 前 的 一 些 类 
进行 了 封装 。 正 如 3.1.2 节 介绍 的 那样 ， 通 过 封装 ， 使 接口 的 易 用 性 和 扩展 性 得 以 增强 。 















































<<interface>> 
Progressable 


+progress () 


fl 


+getTaskAttemptIDQ) :TaskAttemptID 
+setStatus(in msg : String) 


+getLength() : long 
+getLocations() : String[] 


InputFormat 


+getSplits(in context : JobContext ) : List<InputSplit> 
+createRecordReader(in split: InputSplit, in context : TaskAttemptContext) : RecordReader<KEYIN, VA LUEIN> 





3-11 新 API 中 InputFormat 类 图 

















yi 

















此 外 ， 对 于 基 类 FileInputFormat， 新 版 API 中 有 一 个 值得 注意 的 改动 : InputSplit 划 分 算法 不 再 考虑 用 户 设 定 的 Map Task 个 数 ， 而 用 
mapred.max.splitsize Cid NmaxSize) 代 蔡 ， 即 InputSplt 大 小 的 计算 公式 变 为 : 























splitSize=max{minSize, mn {maxSize, blockSize} } 


3.3.3 ”OutputFormat 接 口 的 设计 与 实现 



































OutputFormat 主 要 用 于 描述 输出 数据 的 格式 ， 它 能 够 将 用 户 提 供 的 key/value 对 写 入 特定 格式 的 文件 中 。 本 小 节 将 介绍 Hadoop 如 何 设计 
OutputFormat 接 口 ， 以 及 一 些 常 





























的 OutputFormat 实 现 。 





1. 旧 版 API 的 OutputFormat 解 析 














如 图 3-12 所 示 ， 在 旧版 API 中 ，OutputFormat 是 一 个 接口 ， 它 包含 两 个 方法 : 














RecordWriter<K, V>getRecordWriter (FileSystem ignored, JobConf job, 
String name, Progressable progress) 

throws IOException; 

void checkOutputSpecs (FileSystem ignored, JobConf job) throws IOException; 






























































checkOutputSpecs 方 法 一 般 在 用 户 作 业 被 提交 到 JobTracker 之 前 ， 由 JobClient 自 动 调用 ， 以 检查 输出 目录 是 否 合法 。 


+getRecordWriter(in ignored : FileSystem, in job : JobConf, in name : String, in progress : Progressable) : RecordWriter<K, V> 
+checkOutputSpecs(in ignored : FileSystem, in job : JobConf) 


<<interface> 
Progressable 


= +write(in key: K, in value : V) 
progress () +close(in reporter : Reporter) 





图 3-12 旧版 API 的 OutputFormat 类 图 























多 tRecordWriter 方 法 返回 一 个 RecordWriter 类 对 象 。 该 类 中 的 方法 write 接 收 一 个 key/value 对 ， 并 将 之 写 入 文件 。 在 Task 执 行 过 程 
中 ，MapReduce 框 架 会 将 map0 或 者 reduce0 函 数 产生 的 结果 传 入 write 方法 ， 主 要 代码 〈 经 过 简化 ) 如 下 。 


























public void map (Text key, Text value, 
OutputCollector<Text, Text>output, 

Reporter reporter) throws IOException{ 

// 根 据 当前 key/value 产 生 新 的 输出 <newKey，newVvalue>>， 并 输出 


output.collect (newKey, newValue) ; 














则 函数 output.collect (newKey, newValue) 内 部 执行 代码 如 下 : 





RecordWriter<K, V>out=job.getOutputFormat ().getRecordWriter (......) ; 
out.write (newKey, newValue) ; 


























Hadoop 自 带 了 很 多 OutputFormat 实 现 ， 它 们 与 InputFormat 实 现 相对 应 ， 具 体 如 图 3-13 所 示 。 所 有 基于 文件 的 OutputFormat 实 现 的 基 类 
为 FileOutputFormat， 并 由 此 派生 出 一 些 基 于 文本 文件 格式 、 二 进 制 文 件 格式 的 或 者 多 输出 的 实现 。 









































OutputFormat 


/\ 


DBOutputFormat FileOutputF ormat NullOutputFormat 
AN 
MapFileOutputFormat MnultipleOutputFormat SequenceFileOutputFormat TextOutputFormat 
人 


MultipleSequenceFileOutputFormat MultipleTextOutputF ormat 


图 3-13 Hadoop MapReduce 自 带 OutputFormat 实 现 的 类 层次 图 






































为 了 深入 分 析 OutputFormat 的 实现 方法 ， 我 们 选取 比较 有 代表 性 的 FileOutputFormat 类 进行 分 析 。 同 介绍 InputFormat 实 现 的 思路 一 样 ， 
我 们 先 介绍 基 类 FileOutputFormat， 再 介绍 其 派生 类 TextOutputFormat。 





























基 类 FileOutputFormat 需 要 提供 所 有 基于 文件 的 OutputFormat 实 现 的 公共 功能 ， 总 结 起 来 ， 主 要 有 以 下 两 个 : 





(1) 实现 checkOutputSpecs 接 口 























该 接口 在 作业 运行 之 前 被 调用 ， 默 认 功 能 是 检查 用 户 配置 的 输出 目录 是 否 存在 ， 如 果 存 在 则 抛 出 异常 ， 以 防止 之 前 的 数据 被 覆盖 。 
































(2) 处 理 side-efect file 



































任务 的 side-effect fle 并 不 是 任务 的 最 终 输 出 文件 ， 而 是 具有 特殊 用 途 的 任务 专属 文件 。 它 的 典型 应 用 是 执行 推测 式 任 务 。 在 Hadoop 
中 ， 因 为 硬件 老化 、 网 络 故障 等 原因 ， 同 一 个 作业 的 某 些 任务 执行 速度 可 能 明显 慢 于 其 他 任务 ， 这 种 任务 会 拖 慢 整个 作业 的 执行 速度 。 
为 了 对 这 种 “ 慢 任务 ?进行 优化 ，Hadoop 会 为 之 在 另外 一 个 节点 上 启动 一 个 相同 的 任务 ， 该 任务 便 被 称 为 推测 式 任务 ， 最 先 完成 任务 的 计 
算 结果 便 是 这 块 数据 对 应 的 处 理 结果 。 为 防止 这 两 个 任务 同时 往 一 个 输出 文件 中 写 入 数据 时 发 生 写 冲突 ，FileOutputFormat 会 为 每 个 Task 
的 数据 创建 一 个 side-e 人 Rct fle， 并 将 产生 的 数据 临时 写 入 该 文件 ， 待 Task 完 成 后 ， 再 移动 到 最 终 输出 目录 中 。 这 些 文件 的 相关 操作 ， 比 如 
创建 、 删 除 、 移 动 等 ， 均 由 OutputCommitter 完 成 。 它 是 一 个 接口 ，Hadoop 提 供 了 默认 实现 FileOutputCommitter， 用 户 也 可 以 根据 自己 的 需 
求 编写 OutputCommitter 实 现 ， 并 通过 参数 {mapred.output.committer.class} 指定 。OutputCommitter 接 口 定义 以 及 FileOutputCommitter 对 应 的 实现 
如 表 3-2 所 示 。 
























































































































































表 3-2 OutputCommitter 接口 定义 以 及 FileOutputCommitter 对 应 的 实现 











方法 何 时 被 调用 FileOutputCommitter 实现 
setupJob 作业 初始 化 创建 临时 目录 ${mapred.out.dir}/_ temporary 
commitJob 作业 成 功 运行 完成 删除 临时 目录 ， 并 在 $fmapred.out.dir} 目录 下 创建 空 文件 _ 
SUCCESS 
abortJob 作业 运行 失败 删除 临时 目录 
setupTask 任务 初始 化 se 何 操作 。 原 本 是 需要 在 临时 目录 下 创建 side-effect file 
， 但 它 是 用 时 创建 的 (create on demand) 
needsTaskCommit | 判断 是 否 需 要 提交 结果 只 要 存在 side-effect file， 就 返回 true 
commitTask 任务 成 功 运行 完成 提交 结果 ， 即 将 side-effect file 移动 到 $fmapred.out.dir} 目录 下 
abortTask 任务 运行 失败 删除 任务 的 side-effect file 






































注意 ”默认 情况 下 ， 妆 作业 成 功 运行 完成 后 ， 会 在 最 终结 果 目 录 ${mapred.out.dir} 下 生成 空 文件 _ SUCCESS。 该 文件 主要 为 高 层 应 ) 









































提供 作业 运行 完成 的 标识 ， 比 如 ，Oozie |! 需要 通过 检测 结果 目录 下 是 否 存在 该 文件 判断 作业 是 否 运行 完成 。 











2. 新 版 API 的 OutputFormat 解 析 




















如 图 3-14 所 示 ， 除 了 接口 变 为 抽象 类 外 ， 新 API 中 的 OutputFormat 增 加 了 一 个 新 的 方法 getOutputCommitter， 以 允许 用 户 自己 定制 合 
适 的 OutputCommitter 实 现 。 








+setupJob(in jobContext : JobContext) jp， | 
+commitJob(in jobContext : JobContext ) , 

+abortJob(in jobContext : JobContext, in state : JobStatus. State) RecordWriter 
+setupTask(in taskContext : TaskAttemptContext) 

+needsTaskCommit(in taskContext : TaskAttemptContext) 一 一 - 
+commitTask(in taskContext : TaskAttemptContext) +write(in key : K, in value : V) 
+abortTask(in taskContext : TaskAttemptContext ) +close(in context : TaskAttemptContext) 


OutputFormat 


+getRecordWriter(in context : TaskAttemptContext) : RecordWriter<K, V> 
+checkOutputSpecs(in context : JobContext ) 
+getOutputCommitter (in context : TaskAttemptContext) : OutputCommitter 


图 3-14 新 版 API 的 OutputFormat 尖 图 
[1] 具体 可 到 httpyincubator.apache.oreyoozie/ 下 查看 相关 文档 。 





3.3.4 ”Mapper 与 Reducer 解 析 


1. 旧 版 API 的 Mapper/Reducer 解 析 









































Mapper/Reducer 中 封装 了 应 用 程序 的 数据 处 理 逻 辑 。 为 了 简化 接口 ，MapReduce 要 求 所 有 存储 在 底层 分 布 式 文件 系统 上 的 数据 均 要 解释 
成 key/vValue 的 形式 ， 并 交 给 Mapper/Reducer 中 的 map/reduce 函 数 处 理 ， 产 生 另 外 一 些 key/value。 




















ll 


Oke 


Mapper 与 Reducer 的 类 体系 非常 类 似 ， 我 们 以 Mapper 为 例 进行 讲解 。Mapper 的 类 图 如 图 3-15 所 示 ， 包 括 初 始 化 、Map 操 作 和 清理 
分 。 








<<interface>> 
java.io.Closeable 





+close() 


<<interface> <<interface>> 
JobConfigurable Closeable 
/\ 










+configure (in job : JobConf) 


<<interface> 
OutputCollector<K, V> 


+collect(in key : K, in value : V) 








3-15 ”旧版 API 的 Mapper 类 图 











(1) 初始 化 


























Mapper 继 承 了 JobConfieurable 接 口 。 该 接口 中 的 configure 方 法 允许 通过 JobCon 颂 数 对 Mapper 进 行 初始 化 。 


(2) Map 操 作 


























MapReduce 框 架 会 通过 InputFormat 中 RecordReader 从 InputSplit 获 取 一 个 个 keyvalue 对 ， 并 交 给 下 面 的 mapO 函 数 处 理 : 














void map (K1 key, V1 value, OutputCollector<K2, V2>output, Reporter reporter) throws IOException; 








该 函数 的 参数 除了 key 和 value 之 外 ， 还 包括 OutputCollector 和 Reporter 两 个 类 型 的 参数 ， 分 别 用 于 输出 结果 和 修改 Counter 值 。 








(3) 清理 





























Mapper 通 过 继承 Closeable 接 口 〈 它 又 继承 了 Java IO 中 的 Closeable 接 口 ) 获得 close 方 法 ， 用 户 可 通过 实现 该 方法 对 Mapper 进 行 清理 。 















































MapReduce 提 供 了 很 多 MapperReducer 实 现 ， 但 大 部 分 功能 比较 简单 ， 具 体 如 图 3-16 所 示 。 它 们 对 应 的 功能 分 别 是 : 


























口 ChainMapper/ChainReducer: 用 于 支持 链 式 作业 ， 具 体 见 3.5.2 节 。 











QiIdentityMapper/IdentityReducer: 对 于 输入 keyvalue 不 进行 任何 处 理 ， 直 接 输出 。 








口 InvertMapper: 交换 keyvalue 位 置 。 





口 RegexMapper: 正则 表达 式 字符 串 匹 配 。 

















口 TokenMapper: 将 字符 串 分 割 成 若干 个 token (单词 ) ， 可 用 作 WordCount 的 Mapper。 


口 LongSumReducer: 以 key 为 组 ， 对 long 类 型 的 value 求 累加 和 。 












Chain Mapper 





IdentityMapper InvertMapper 


RegexMapper TokenMapper 









ChainReducer IdentityReducer LongSumReducer 


3-16 Hadoop MapReduce 自 带 Mapper/Reducer 实 现 的 类 层次 图 




































































对 于 一 个 MapReduce 应 用 程序 ， 不 一 定 非 要 存在 Mapper。MapReduce 框 架 提 供 了 比 Mapper 更 通用 的 接口 :MapRunnable， 如 图 3-17 所 示 。 
用 户 可 以 实现 该 接口 以 定制 Mapper 的 调用 方式 或 者 自己 实现 key/value 的 处 理 逻 辑 ， 比 如 ，Hadoop Pipes 自 行 实现 了 MapRunnable， 直 接 将 数据 
通过 Socket 发 送 给 其 他 进程 处 理 。 提 供 该 接口 的 另外 一 个 好 处 是 允许 用 户 实现 多 线程 Mapper。 


<<interface>> 
JobConfigurable 


/\ 


<<interface>> 
MapRunnable<K1, V1, K2, V2> 


+run(in input : RecordReader<K1, V1>, in output : OutputCollector<K2, V2>, in reporter : Reporter) 







































































































图 3-17 MapRunnable 类 图 


























如 图 3-18 所 示 ，MapReduce 提 供 了 两 个 MapRunnable 实 现 ， 分 别 是 MapRunner 和 IMultithreadedMapRunner， 其 中 MapRunner 为 默认 实现 。 
MultithreadedMapRunner 实 现 了 一 种 多 线程 的 MapRunnable。 默 认 情 况 下 ， 每 个 Mapper 启 动 10 个 线程 ， 通 常用 于 非 CPU 类 型 的 作业 以 提供 吞吐 















































[MapRunnable<K1, V1, K2, v>| 


— 


MapRunner<K1, V1, K2, V2> MultithreadedMapRunner<K1, V1, K2, V2> 


图 3-18 Hadoop MapReduce 自 带 MapRunnable 实 现 的 类 层次 


























2. 新 版 API 的 MapperReducer 解 析 











从 图 3-19 可 知 ， 新 API 在 旧 API 基 础 上 发 生 了 以 下 几 个 变化 : 

















<<interface> 
Progressable 


人 


TaskAttemptConte 


Ee 
Ps == 到 
/\ 


TaskInputOutputContext <KEYIN, VA LUEIN, KEYOUT, 





VA LUEOUT> 
-output : RecordWriter<K, V> 
-reporter : StatusReporter 
<ommitter : OutputCommitter 
+nextKeyV aluef) 
+getCurrentKey{) : KEYIN 
+getCurrentValue{) :VALUEIN 
+write(in key, in value) 
+getCounter(in courterName : Enum) : Courter 
+getCourter(in groupName : String, in counterName : String) : Courter 
+progress() 
+setStatus(in status : String) 
+getOutputCommitter () ; OutputCommitter 





MapContext <KEYIN.VA LUEIN, KEYOUT, VA LUEOUT> 


«reader : RecordReader<KEYIN, VA LUEIN> 
split : InputSplit 


ReduceContext <KEYIN, VA LUEIN,KEY OUT, VA LUEOUT> 

iterable : Valuelterable 

eporter : Progressable 
+ReduceContext(in conf, in taskid, in inpuKeyCourter, in inputValueCounter, in ...) 
+getCurrentKey) : KEYIN 
+getCurrentValue() : VA LUEIN 
H+nextKeyValue{) : bodean 

etValues() :Iterable<VA LUEIN> 


+MapContext(in conf, in taskid, in reader, in writer, in committer, in reporter, in split) 
+getInputSplit() :InputSplit 

+getCurrentKey()Q) :KEYIN 

+getCurrentValue() :VA LUEIN 

+nextKeyValue{) :boalcan 





aS ÉN 


1 1 


*setup(in context : Mapper.Context) tsetup(in context : Reducer, Context) 


+map(in key, in value, in context ; Mapper.Context) +reduce(in key : KEYIN in values : Iterable<VA LUEIN», in context : Reducer,Context) 
+cleanup(in context : Mapper Context ) +cleanup(in context : Mapper.Context) 
+run(in context : Mapper Context) +run(in context : Reducer.Context) 








图 3-19 ”新 版 API 的 Mapper/Reducer 类 图 












































口 Mapper 由 接口 变 为 抽象 类 ， 且 不 再 继承 JobConfgurable 和 Closeable 两 个 接口 ， 而 是 直接 看 
和 清理 工作 。 





E 类 中 添加 了 setup 和 cleanup 两 个 方法 进行 初始 化 











口 将 参数 封装 到 Context 对 象 中 ， 这 使 得 接口 具有 良好 的 扩展 局 























nF 








口 去 掉 MapRunnable 接 口 ， 在 Mapper 中 添加 run 方 法 ， 以 方便 用 户 定 























制 mmapO 函 数 的 调用 方法 ，run 默 认 实 现 与 旧版 本 中 MapRunner 的 ru 实现 


| 
3 
2 























口 新 API 中 Reducer 遍 历 value 的 迭代 器 类 型 变 为 java.lang Iterable， 使 得 用 户 可 以 采用 ‘foreach 形式 遍历 所 有 value， 如 下 所 示 : 


























void reduce (KEYIN key, Iterable<VALUEIN>values, Contex 
) throws IOException, InterruptedException{ 

for (VALUEIN value: values) {// 注 意 遍历 方式 

context.write ( (KEYOUT) key, (VALUEOUT) value) ; 

} 
} 


t context 





3.3.5 ”Partitioner 接 口 的 设计 与 实现 














Partitioner 的 作用 
段 的 负载 均衡 。| 


























个 待 实现 的 方法 getPartition。 该 方法 


是 对 Mapper 产 生 的 中 
APIA 





hPartitioner 的 类 
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果 进 行 分 片 ， 以 便 将 同一 分 台 
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含 三 个 参数 ， 均 




















个 Mapper 的 分 片 数 ， 也 就 是 Reducer 的 个 数 。 


MapReduce 提 供 了 两 个 Partitioner 实 现 : HashPartitionerfllTotalOrderPartitioner. $24 
的 分 片 方法 ， 代 码 如 下 : 
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的 数 






































版 API 的 Partitioner 类 
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昌 交 给 同一 个 Reducer 处 理 ， 它 直接 影 
3-20 所 示 。 它 继承 了 JobConfigurable， 可 通过 configure 方 法 初始 化 。 它 本 身 
框架 自动 传 入 ， 前 面 两 个 参数 是 keyvalue， 第 三 个 参数 numPartitions 表 示 每 


<<interface> 
JobConfigurable 


+configure (in job : JobConf) 


<<interface> 
Partitioner<K2, V2> 


+getPartition(in key : K2, in value : K2, in numPartitions : int) : int 


向 Reduce 阶 
只 包含 

















PHashPartitioner 是 默认 实现 ， 它 实现 了 一 种 基 








public int getPartition (K2 key, V2 value, 
int numReduceTasks) { 
return (key. hashCode () & Integer.MAX VALUE) %numReduceTasks; 


} 























TotalOrderPartitionert (t S — PET X al Oy HT 


ER 


是 归 


一 个 Reduce Task, 
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TotalOrderPartitioner. 
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这 使 





步骤 1 


RandomSampler、SpltSampler 等 〈 具 


Pr ob 


B Re 


排序 ， 即 在 Map 阶 段 ， 每 个 Map Task 进 行 
而 Reduce 阶 段 会 成 为 作业 的 瓶颈 。 为 了 提高 
够 按照 大 小 将 数据 分 成 若干 个 
租 全 排序 的 步 又 如 下 : 














， 通 常用 在 数据 全 排序 中 。 
局 部 排序 ， 在 Reduce 阶 段 ， 启 动 一 个 Reduce Task 进 行 

















数据 采样 。 在 Client 峭 通过 采样 获取 分 片 的 
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api 





采样 数据 为 : b, abc, abd, bed, abcd, efg, hii, afd, rrr, mnk 


区 间 《〈 分 片 ) ， 


Ls 

















Bx 





在 MapReduce 环 境 中 ， 容 易 想到 的 全 排序 方案 
fat 





F 序 。 由 于 作业 只 能 有 











局 排序 的 性 能 和 扩展 性 ，MapReduce 提 供 了 











并 保 订 














EF 后 
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区 间 的 所 有 数据 均 大 于 前 一 个 





区 间 数 据 ， 


上 点 。Hadoop 自 带 了 几 个 采样 算法 ， 如 IntercalSampler、 


经 排序 后 得 到 : abc, abcd, abd, afd, b, bed, efg, hi mnk, rrr 
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步骤 2 Map 阶段 。 本 
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出 ， 但 Partitioner 必 须 选 上 











|TotalOrderPartitioner, “(1422 3814 


阶段 涉及 两 个 组 件 ， 分 别 是 Mapper 和 Partitioner。 其 中 








H3 


体 见 orgapache.hadoop.mapred. 了 b 包 中 的 InputSampler 类 ) > F% 








取 的 分 割 点 保存 到 trie 树 中 以 便 快速 定位 任 i 








间 ， 这 样 ， 每 个 Map Task ÆR (Reduce Task 个 数 ) 个 区 间 ， 且 区 间 之 间 有 序 。 


TotalOrderPartitioner 通 过 trie 树 查找 每 条 记录 所 对 应 的 Reduce Task 编 号 。 如 图 
FTE abg Hmmz, NIFE “abg 对 应 partition] , 


中 ， 假 设 输入 数据 中 有 
即 第 4 个 Reduce Task。 
































PF，Mapper 可 采 


ee 























果 Reduce Task 个 数 为 4， 则 采样 数据 的 四 等 分 点 为 abd、bcd、mnk， 将 这 3 个 字符 串 作 为 分 割 点 。 














举例 说 明 。 








用 IdentityMapper， 直 接 将 输入 数据 



































3-21 所 示 ， 我 们 闪 





即 第 2 个 Reduce Task, Z4 H 
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个 记录 所 在 的 区 


分 割 点 保存 在 深度 为 2 的 trie 树 








nz 对 应 partition3， 





| partition3 


partition 0 i partition! partition2 


























图 3-21 利用 tre 树 对 数据 进行 分 片 


























步骤 3 ” Reduce 阶段 。 每 个 Reducer 对 分 配 到 的 区 间 数 据 进 行 局 部 排序 ， 最 终 得 到 全 排序 数据 。 




















从 以 上 步骤 可 以 看 出 
越 具有 代表 性 ， 则 Reduce Task 负 载 越 均 衡 ， 全 排序 效率 越 高 。 



































TotalOrderPartitioner 有 两 个 典型 的 应 用 实例 : TeraSort 和 HBase 批 量 数据 导入 。 其 中 ，TeraSort 是 Hadoop 自 并 





























基于 TotalOrderPartitioner 全 排序 的 效率 跟 key 分 布 规律 和 采样 算法 有 直接 关系 ; key 值 分 布 越 均 匀 且 
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例 。 它 曾 在 TB 级 数据 排序 基准 评估 中 赢得 第 一 名 (由 ， 而 TotalOrderPartitioner 正 是 从 该 实例 中 提炼 出 来 的 。HBase H E — ANE 
Hadoop 之 上 的 NoSQI 数 据 仓库 。 它 以 Region 为 单位 划分 数据 ，Region 内 部 数据 有 序 〈 按 key 排序 ) ，Region 之 间 也 有 序 。 很 明显 ， 





一 个 MapReduce 全 排序 作业 的 R 个 输出 文件 正好 可 对 应 HBase 的 R 个 Region。 








lK 





























新 版 API 中 的 Partitioner 类 图 如 图 3-22 所 示 。 它 不 再 实现 JobConfigurable 接 
化 时 ， 可 自行 实现 Configurable 接 口 ， 如 : 














用 户 需 要 让 Partitioner 通 过 某 个 JobConf 对 象 初始 





public class TotalOrderPartitioner<K, V> 
extends Partitioner<K, V>implements Configurable 





Partitioner 


+getPartition(in key : KEY, in value : VALUE, in numPartitions : int) : int 








X 











3-22 ”新 版 API 中 的 Partitioner 类 





[1] http/sortbenchmark. org/ 
[2] http/hbase. apache.org/ 








3.4 4EJava API 解 析 














3.4.1 Hadoop Streaming 的 实现 原理 


iT 

















Hadoop Streaming 是 Hadoop 为 方便 非 Java 用 户 编写 MapReduce 程 序 而 设计 的 工具 包 。 它 允许 用 户 将 任何 可 执行 文件 或 者 脚本 作 
为 Mapper/Reducer， 这 大 大 提高 了 程序 员 的 开发 效率 。 





























Hadoop Streaming 要 求 用 户 编写 的 MapperReducer 从 标准 输入 中 读 取 数据 ， 并 将 结果 写 到 标准 数据 中 ， 这 类 似 于 Linux 中 的 


机 种 
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1.Hadoop Streaming 编 程 实例 
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以 WordCount 为 例 ， 可 用 C++ 分 别 实现 Mapper 和 Reducer， 有 具体 方法 如 下 《这 里 仅 是 最 简单 的 实现 ， 并 未 全 面 考 虑 各 种 异常 情 


UL) 。 




















Mapper 实 现 的 具体 代码 如 下 : 



































int main() {//Mapper 将 会 被 封装 成 一 个 独立 进程 ， 因 而 需要 有 main () 函数 


string key; 


while (cin>>key) {// 从 标准 输入 流 中 读 取 数据 





// 输 出 中 间 结 果 ， 默 认 情况 下 TAB 为 key/value 分 隔 符 





cout<<key<<"\t"<<"1"<<endl; 
} 


return 0; 


} 




















Reducer 实 现 的 具体 代码 如 下 : 











int main() {//Reducer 将 会 被 封装 成 一 个 独立 进程 ， 因 而 需要 有 main () 函数 


string cur key, last key, value; 
cin>>cur_key>>value; 
last_key=cur_key; 

int n=1; 


while (cin>>cur_key) {// 读 取 Map Task 输 出 


cin>>value; 

if (last_key! =cur_key) {// 识 别 下 一 个 key 
cout<<last_key<<"\t"<<n<<endl; 
last_key=cur_key; 

n=1; 

}else{// 获 取 key 相 同 的 所 有 value 数 目 

n++; //key 值 相同 的 ， 累 计 value 值 

} 


} 


return 0; 


} 
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分 别 编译 这 两 个 程序 ， 生 成 的 可 执行 文件 分 别 是 wc_mapper 和 wec reducer, JK ÈM] #llcontrib/streaming/hadoop-streaming- 



































1.0.0.jar 一 起 复制 到 Hadoop 安 装 目 录 下 ， 使 用 以 下 命令 提交 作业 : 


























$HADOOP HOME/bin/hadoop jar$HADOOP HOJ 
-files wc mapper, wc_reducer\ 
-input/test/intput\ 
-output/test/output\ 

-mapper wc_mapper\ 

-reducer wc_reducer 











/hadoop-streaming-1.0.0.jar\ 





























由 于 Hadoop Streaming 类 似 于 Linux 管 道 ， 这 使 得 测试 变 得 非常 容易 。 用 户 可 直接 在 本 地 使 用 下 












































甸 命 令 测 试 结果 是 否 正确 : 









































cat test.txt|./wc_mapper|sort|./wc_reducer 








2.Hadoop Streaming 实 现 原理 分 析 























Hadoop Streaming 工 具 包 实际 上 是 一 个 使 





jJava 编 写 的 MapReduce 作 业 。 当 用 户 使 用 可 执行 文件 或 者 脚本 文件 充当 Mapper 或 者 








Reducer 时 ，Java 端 的 Mapper 或 者 Reducer 充 当 了 wrapper 角 色 ， 它 们 将 输入 文件 中 的 key 和 Value 直接 传递 给 可 执行 文件 或 者 脚本 文件 
进行 处 理 ， 并 将 处 理 结果 写 入 HDFS。 
























































实现 Hadoop Streaming 的 关键 技术 点 是 如 何 使 用 标准 输入 输出 实现 Java 与 其 他 可 执行 文件 或 者 脚本 文件 之 间 的 通信 。 为 
Jt, Hadoop Streaming 使 用 了 JDK 中 的 java.lang,ProcessBuilder 类 。 该 类 提供 了 一 整套 管理 操作 系统 进程 的 方法 ， 包 括 创 建 、 启 动 和 
停止 进程 (也 就 是 应 用 程序 ) 等 。 相 比 于 JDK 中 的 Process 类 ，ProcessBuilder 允 许 用 户 对 进程 进行 更 多 控制 ， 包 括 设置 当前 工作 目 
录 、 改 变 环 境 参 数 等 。 


































































































下 面 分 析 Mapper 的 执行 过 程 (Reducer 的 类 似 ) 。 整 个 过 程 如 图 3-23 所 示 ，Hadoop Streaming 使 用 ProcessBuilder 以 独立 进程 方式 
启动 可 执行 文件 wc_ mapper， 并 创建 该 进程 的 输入 输出 流 ， 有 具体 实现 代码 如 下 : 









































// 将 wc_mapper 封 装 成 一 个 进程 

ProcessBuilder builder=new ProcessBuilder ("wc mapper") ; 
builder.environment () .putAll (childEnv.toMap()) ;，// 设 置 环 境 变量 
sim=builder.start(); 

// 创 建 标准 输出 流 

clientOut_=new DataOutputStream (new BufferedOutputStream ( 
im.getOutputStream(), 

UFFER SIZE) ) ; 

/创建 标准 输入 流 

lientIn_=new DataInputStream (new BufferedInputStream ( 
im.getInputStream(), 

UFFER SIZE) ) ; 

/创建 标准 错误 流 

lientErr =new DataInputStream (new 

ufferedInputStream (sim.getErrorStream()) ) ; 
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3-23 Hadoop Streaming 工 作 原 理 图 




















Hadoop Streaming 提 供 了 一 个 默认 的 PipeMapper。 它 实际 上 是 C++ 端 Mapper 的 wrapper， 主 要 作用 是 向 已 经 创建 好 的 输出 流 
clientOut 中 写 入 数据 ， 有 具体 实现 代码 如 下 : 











public void map (Object key, Object value, OutputCollector output, Reporter 
reporter) throws IOException { 





clientOut_.write (key, 0, keySize) ; 
clientOut_.write (mapInputFieldSeparator) ; 
clientOut_.write (value, 0, valueSize) ; 
clientOut_.write ('\n') ; 


} 














写 入 clientOut 的 数据 直接 成 为 wc_mapper 的 输入 ， 待 数据 被 处 理 完 后 ， 可 直接 从 标准 输入 流 clientIn 中 获取 结果 : 














//MROutputThread 


public void run() { 

lineReader=new LineReader ( (InputStream) clientIn_, job ); 
while (lineReader.readLine (line) >0) { 

splitKeyVal (line, line.getLength(), key, val); 
output.collect (key, val) ; 

} 

} 


























通过 分 析 以 上 代码 可 知 ， 由 于 Hadoop Streaming 使 用 分 隔 符 定位 一 个 完整 的 key 或 value， 因 而 只 能 支持 文本 格式 数据 ， 不 支持 




















二 进 制 格式 。 在 0.21.0/0.22.X 系 列 版 本 中 ，Hadoop Streaming 增 加 了 对 二 进 制 文件 的 支持 中 ， 并 添加 了 两 种 新 的 二 进 制 文件 格式 ; 
RawBytes 和 TypedBytes。 顾 名 思 义 ，RawBytes 指 key 和 value 是 原始 字 节 序列 ， 而 TypedBytes 指 key 和 value 可 以 拥有 的 数据 类 型 ， 比 如 
boolean、lst、map 等 。 由 于 它们 采用 的 是 长 度 而 不 是 某 一 种 分 隔 符 定位 key 和 value， 因 而 支持 二 进 制 文件 格式 。 






























































RawBytes 传 递 给 可 执行 文件 或 者 脚本 文件 的 内 容 编码 格式 为 : 











<4 byte length><key raw bytes><4 byte length><value raw bytes> 

















TypedBytes 允 许 用 户 为 key 和 value 指 定数 据 类 型 。 对 于 长 度 固定 的 基本 类 型 ， 如 byte、bool、int、long 等 ， 其 编码 格式 为 : 











<1 byte type code><key bytes><1 byte type code><value bytes> 








T 











对 于 长 度 不 固定 的 类 型 ， 如 byte array、string 等 ， 其 编码 格式 为 : 








<1 byte type code><4 byte length><key raw bytes><1 byte type code><4 byte length><value raw bytes> 














当 key 和 value 大 部 分 情况 下 为 固定 长 度 的 基本 类 型 时 ，TypedBytes 比 RawBytes 格 式 更 节省 空间 。 





[1] https//Assues. apache.org/jira/browse/HADOOP- 1722 


3.4.2 Hadoop Pipes 的 实现 原理 











Hadoop Pipes 是 Hadoop 为 方便 CC++ 用 户 编写 MapReduce 程 序 而 设计 的 工具 。 其 设计 思想 是 将 应 用 逻辑 相关 的 C++ 代码 放 在 单 
独 的 进程 中 ， 然 后 通过 Socketi 上 Java 代 码 与 C++ 代码 通信 以 完成 数据 计算 。 





























1 .编程 实例 











同样 ， 以 WordCount 为 例 ， 采 用 C++ 分 别 编写 Mapper 和 Reducer， 有 具体 方法 如 下 。 




















Mapper 实 现 的 具体 代码 如 下 : 











class WordCountMapper: public HadoopPipes: Mapper{// 注 意 基 类 
public: 

WordCountMapper (HadoopPipes: TaskContext&context) { 

// 在 此 初始 化 ， 比 如 定义 计数 器 等 

} 
//MapContext 封 装 了 Mapper 的 各 种 操作 

void map (HadoopPipes: MapContext&context) { 

std: vector<std: string>words= 

HadoopUtils: splitString (context.getInputValue(), "") ; 
for (unsigned int i=0; i<words.size(); ++i) { 
context.emit (words[i], "1") ; // 用 emit 输 出 key/value 对 

} 

} 

}; 















































Reducer 实 现 的 具体 代码 如 下 : 





class WordCountReducer: public HadoopPipes: Reducer{ 
public: 
WordCountReducer (HadoopPipes: TaskContext&context) { 


} 

//ReduceContext 封 装 了 Reducer 的 各 种 操作 

void reduce (HadoopPipes: ReduceContext&context) { 

int sum=0; 

while (context.nextValue()) {// 友 代 获 取 该 key 对 应 的 value 列 表 
sum+=HadoopUtils: toInt (context.getInputValue()) ; 

} 

context.emit (context.getInputKey(), HadoopUtils: toString (sum) ) ; 
} 

}s 





main0 函 数 的 具体 实现 代码 如 下 : 

















// 每 个 Hadoop Pipes 作 业 将 被 单独 封装 成 一 个 进程 ， 因 此 需要 有 main () 函数 

int main (int argc, char*argv[]) { 

return HadoopPipes: runTask ( 

HadoopPipes: TemplateFactory<WordCountMap, WordCountReduce> ()) ; 











编译 之 后 生成 可 执行 文件 wordcount， 输 入 以 下 命令 运行 作业 : 











bin/hadoop pipes\ 

-D hadoop.pipes.java.recordreader=true\ 
-D hadoop.pipes.java.recordwriter=true\ 
-D mapred.job.name=wordcount\ 
-input/test/intput\ 
-output/test/output\ 

-program wordcount 














与 Hadoop Streaming 比 较 ， 可 以 发 现 ，Hadoop Pipes 的 一 个 缺点 是 调试 不 方便 。 因 为 输入 的 数据 是 Java 端 代码 通过 Socket 传 到 
C++ 应 用 程序 的 ， 所 以 用 户 不 能 单独 对 C++ 部 分 代码 进行 测试 ， 而 需要 连同 Java 端 代码 一 起 启动 。 


























2. 实 现 原理 分 析 




















Hadoop Pipes 的 实现 原理 与 Hadoop Streaming 非 常 类 似 ， 它 也 使 用 Java 中 的 ProcessBuilder 以 单独 进程 方式 启动 可 执行 文件 。 不 同 
之 处 是 Java 代 码 与 可 执行 文件 〈 或 者 脚本 ) 的 通信 方式 : Hadoop Streaming 采 用 标准 输入 输出 ， 而 Hadoop Pipes 采 用 Socket。 



































Hadoop Pipes 由 两 部 分 组 成 : Java 端 代码 和 C++ 端 代 码 。 与 Hadoop Streaming 一 样 ，Java 端 代码 实际 上 实现 了 一 个 MapReduce 作 
业 ，JjJava 端 的 Mapper 或 者 Reducer 实 际 上 是 C++ 端 Mapper 或 者 Reducer 的 封装 器 (wrapper) ， 它 们 通过 Socket 将 输入 的 key 和 value 直 
接 传递 给 可 执行 文件 执行 。 
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Hadoop Pipes 具 体 执行 流程 如 图 3-24 所 示 。 该 序列 图 曾 释 了 执行 Mapper 时 ，Java 端 与 C++ 端 通过 Socket 进 行 交 互 的 过 程 ， 主 
有 以 下 几 个 步 又; 





























步骤 1 用 户 提交 Pipes 作 业 后 ，Java 端 启动 一 个 Socket server 〈 等 待 C++ 端 接 入 ) ， 同 时 以 独立 进程 方式 运行 C++ 端 代 码 。 














步骤 2 ”C++ 端 以 Client 身 份 连接 Java 端 的 Socket server， 连 接 成 功 后 ，Java 端 依次 发 送 一 系列 指令 通知 C++ 端 进行 各 项 准备 工 
作 。 


























步骤 3 Java 端 通过 mapItemO 函 数 不 断 向 C++ 端 传送 keyvalue 对 ，C++ 端 将 计算 结果 返回 给 Java 端 ，Java 端 对 结果 进行 保存 。 



































步骤 4 所 有 数据 处 理 完毕 后 ，Java 端 通知 C++ 端 终止 计算 ， 并 关闭 C++ 端 进程 。 
































上 面 分 析 了 Java 端 与 C++ 端的 交互 过 程 ， 接 下 来 深入 分 析 Hadoop Pipes 内 部 实现 原理 。 如 图 3-25 所 示 ，Java 端 用 
PipesMapRunner 实 现 了 MapRunner， 在 MapRunner 内 部 ， 借 助 两 个 协议 类 DownwardProtocol 和 UpwardProtocol 向 C++ 端 发 送 数据 和 从 
C++ 端 接收 数据 ， 而 C++ 端 也 有 两 个 类 与 之 对 应 ， 分 别 是 Protocol 和 UpwardProtocol。Protocol 将 收 到 的 数据 传 给 用 户 编写 的 
Mapper， 经 Mapper、Conibiner 和 Partitioner 处 理 后 ， 由 UpwardProtocol 返 回 给 Java 端 的 UpwardProtocol， 由 它 写 到 本 地 磁盘 上 。 













































































Java(server) C++(client) 
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LJ start() kd 


runMap(split,numberReduces,pipedInpuĵ 


setInputsType (keyType,valueType) 























3-24 Hadoop Pipes 中 Java 端 与 C++ 端 交 互 序列 图 
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3-25 Hadoop Pipes 内 部 实现 原理 





3.5 Hadoop 工 作 流 








前 面 仅 是 介绍 了 单一 作业 的 编写 方法 ， 很 多 情况 下 ， 用 户 编写 的 作业 比较 复杂 ， 相 互 之 间 存 在 依赖 关系 ， 这 利 



































3.$.1 JobContro] 的 实现 原理 


做 法 是 : 为 每 个 作业 创建 相应 的 JobConf 对 象 ， 并 按照 依赖 关系 依次 〈“ 串 行 ) 提交 各 个 作业 ， 如 下 所 示 : 








I 有 向 图 表示 ， 我 们 称 之 为 “工作 流 ”。 本 节 将 介绍 Hadoop 工 作 流 的 编写 方法 、 设 计 原 理 以 及 实现 。 
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1 JobControg fE X fil 









































我 们 以 第 2 章 中 的 贝 叶 斯 分 类 为 例 介 绍 。 一 个 完整 的 贝 叶 斯 分 类 算法 可 能 需要 4 个 有 依赖 关系 的 MapReduce 作 业 完 成 ， 

















依赖 关系 可 以 


传统 的 











// 为 4 个 作业 分 别 创建 JobConf 对 象 
JobConf extractJobConf=new JobConf (ExtractJob.class) ; 

JobConf classPriorJobConf=new JobConf (ClassPriorJob.class) ; 

JobConf conditionalProbilityJobConf=new JobConf (ConditionalProbilityJob.class) ; 
JobConf predictJobConf=new JobConf (PredictJob.class) ; 

se / /配置 各 个 JobConf 

/ /按照 依赖 关系 依次 提交 作业 

JobClient.runJob (extractJobConf) ; 

JobClient.runJob (classPriorJobConf) ; 

JobClient.runJob (conditionalProbilityJobConf) ; 

JobClient.runJob (predictJobConf) ; 











具体 代码 如 下 : 









































oT 









































如 果 使 用 JobControl， 则 用 户 只 需 使 用 addDepending0 函 数 添加 作业 依赖 关系 接口 ，JobControl 会 按照 依赖 关系 调度 各 个 作业 ， 








让 





Configuration extractJobConf=new Configuration (); 

Configuration classPriorJobConf=new Configuration (); 
Configuration conditionalProbilityJobConf=new Configuration (); 
Configuration predictJobConf=new Configuration (); 

AN // 设 置 各 个 Configuration 

/ /创建 Job 对 象 。 注 意 ，JobControl 要 求 作业 必须 封装 成 Job 对 象 

Job extractJob=new Job (extractJobConf) ; 

Job classPriorJob=new Job (classPriorJobConf) ; 

Job conditionalProbilityJob=new Job (conditionalProbilityJobConf) ; 
Job predictJob=new Job (predictJobConf) ; 

// 设 置 依赖 关系 ， 构 造 一 个 DAG 作 业 

classPriorJob.addDepending (extractJob) ; 
conditionalProbilityJob.addDepending (extractJob) ; 
predictJob.addDepending (classPriorJob) ; 
predictJob.addDepending (conditionalProbilityJob) ; 

/ /创建 JobControl 对 象 ， 由 它 对 作业 进行 监控 和 调度 
JobControl JC=new JobControl ("Native Bayes") ; 
JC.addJob (extractJob) ; // 把 4 个 作业 加 入 JobControl 中 
JC.addJob (classPriorJob) ; 

JC.addJob (conditionalProbilityJob) ; 

JC.addJob reno se 

JC.run(); // 提 交 DAG 作 业 


















































在 实际 运行 过 程 中 ， 不 依赖 于 其 他 任何 作业 的 extractJob 会 优先 得 到 调度 ， 一 旦 运行 完成 ，classPriorJob 和 conditionalProbilityJob 














= 


依赖 作业 的 运行 状态 ， 以 此 更 新 自己 的 状态 ， 其 状态 转移 图 如 图 3-26 所 示 。 作 业 刚 开始 处 于 WAITING 状 态 。 


RUNNING 状 态 。 在 RUNNING 状 态 下 ， 根 据 作 业 运 行情 况 ， 可 能 进入 SUCCESS 或 者 FAILED 状 态 。 需 要 注意 的 是 ， 如 果 





个 作业 同时 被 调度 ， 待 它们 全 部 运行 完成 后 ，predictJob 被 调度 。 

















Mog 


对 比 以 上 两 种 方案 ， 可 以 得 到 一 个 简单 的 结论 : 使 用 JobControl 编 号 DAG 作 业 更 加 简便 ， 且 能 





运行 。 











2.JobControl 设 计 原 理 分 析 


























使 多 个 无 依赖 关系 的 作业 并 行 





JobControl 由 两 个 类 组 成 : Jobb 和 JobControl。 其 中 ，Job 类 封装 了 一 个 MapReduce 作 业 及 其 对 应 的 依赖 关系 ， 主 要 负责 监控 各 个 
如 果 没 有 依赖 作业 
或 者 所 有 依赖 作业 均 已 运行 完成 ， 则 进入 READY 状 态 。 一 旦 进入 READY 状 态 ， 则 作业 可 被 提交 到 Hadoop 集 群 上 运行 ， 并 进入 






























































个 作业 











的 依赖 作业 失败 ， 则 该 作业 也 会 失败 ， 了 


(waitingJobs) 


(readyJobs) 


(runningJobs) 


(successfulJobs) 


JobContro 圭 装 了 一 系列 MapReduce 作 业 及 其 








RE 








成 “多 米 诺 骨牌 效应 ” 后 续 所 有 作业 均 会 失败 。 









WAITING 







(failedJobs) 


RUNNING 
FAILED 


SUCCESS 








3-26 ”JobControl 中 Job 状 态 转移 图 




















对 应 的 依赖 关系 。 它 将 处 于 不 同 状态 的 作业 放 入 不 同 的 哈 希 表 中 ， 并 按照 图 3-26 





所 示 的 状态 转移 作业 ， 直 到 所 有 作业 运行 完成 。 在 实现 的 时 候 ，JobControl 包 含 一 个 线程 用 于 周期 性 地 览 控 和 更 新 各 个 作业 的 运 

















行 状 态 ， 
程 





























调度 依赖 作业 运行 完成 的 作业 ， 提 交 处 于 READY 状 态 的 作业 等 。 同 时 ， 它 还 提供 了 一 些 API 用 于 挂 起 、 恢 复 和 和 暂停 该 线 





3.5.2 ”ChainMapper/ChainReducer 的 实现 原理 





ChainMapperChainReducer 主 要 为 了 解决 线性 链 式 Mapper 而 提出 的 。 也 就 是 说 ， 在 Map 或 者 Reduce 阶 段 存 在 多 个 Mapper， 


这 些 
Mapper 像 Linux 管 道 一 样 ， 前 一 个 Mapper 的 输出 结果 直接 习 

















定向 到 下 一 个 Mapper 的 输入 ， 形 成 一 个 流水 线 ， 形 式 类 似 于 

[MAP+REDUCE MAP*]。 图 3-27 展 示 了 一 个 典型 的 ChainMappervChainReducer 的 应 用 场景 : 在 Map 阶 段 ， 数 据 依 次 经 过 Mapper1 和 
Mapper2 处 理 ， 在 Reduce 阶 段 ， 数 据 经 过 shuffe 和 sort 后 ; 交 
是 交 给 另外 一 个 Mapper 处 理 
































对 应 的 Reducer 处 理 ， 但 Reducer 处 理 之 后 并 没有 直接 写 到 HDFS 上 ， 而 
它 产生 的 结果 写 到 最 终 的 HDFS 输 出 目录 中 。 






































Map Task 


Reduce Task 
Mapperl Mapper2 











图 3-27 ChainMapper/ChainReducer 应 用 实例 
































需要 注意 的 是 ， 对 于 任意 一 个 MapReduce 作 业 ，Map 和 Reduce 阶 段 可 以 有 无 限 个 Mapper， 但 Reducer 只 能 有 一 个 。 也 就 是 说 ， 
图 3-28 所 示 的 计算 过 程 不 能 使 





月 ChainMapper/ChainReducer 完 成 ， 而 需要 分 解 成 两 个 MapReduce 作 业 。 











图 3-28 一 个 ChainMapper/ChainReducer 不 适用 的 场景 
1. 编 程 实例 


这 里 以 图 3-27 中 的 作业 为 例 ， 给 出 ChainMapper/ChainReducer 的 基本 使 用 方法 ， 具 体 代 码 如 下 : 








conf.setJobName ("chain") ; 
conf.setInputFormat (TextInputFormat.class) ; 
conf.setOutputFormat (TextOutputFormat.class) ; 
JobConf mapperlConf=new JobConf (false) ; 
JobConf mapper2Conf=new JobConf (false) ; 
JobConf reducelConf=new JobConf (false) ; 
JobConf mapper3Conf=new JobConf (false) ; 





ChainMapper.addMapper (conf, Mapperl.class, LongWritable.class, Text.class, Text.class, Text.class, true, 
mapperlConf) ; 


ChainMapper.addMapper (conf, Mapper2.class, Text.class, Text.class, LongWritable.class, Text.class, false, 
mapper2Conf) ; 


ChainReducer.setReducer (conf, Reducer.class, LongWritable.class, Text.class, Text.class, Text.class, true, 
reducelConf) ; 


ChainReducer.addMapper (conf, Mapper3.class, Text.class, Text.class, LongWritable.class, Text.class, false, 


null) ; 
JobClient.runJob (conf) ; 






































用 户 通 过 addMapper 在 Map/Reduce 阶 段 添加 多 个 Mapper。 该 函数 带 有 8 个 输入 参数 ， 分 别 是 作业 的 配置 、Mapper 类 、Mapper 的 














输入 key 类 型 、 输 入 value 类 型 、 输 出 key 类 型 、 输 出 value 类 型 、key/value 是 否 按 值 传 递 和 Mapper 的 配置 。 其 中 ， 和 第 7 个 参数 需要 解释 


— F: Hadoop MapReduce 有 一 个 约定 ， 函 数 OutputCollector.collect (key, value〉 执 行 期 间 不 应 改变 key 和 value 




















数 Mapper.map0 调 用 完 OutputCollector.collect (key, value) Z/a, TAES F 















































了 次 使 用 key 和 value 值 ， 


























tp 


值 。 这 主要 是 因为 函 
如 果 被 改变 ， 可 能 会 造成 潜在 的 错 























误 。 为 了 防止 OutputCollector 直 接 对 key/Value 修 改 ，ChainMapper 人 允许 用 户 指定 key/value 传 递 方式 。 如 果 用 户 确定 key/Value 不 会 被 修 








改 ， 则 可 选用 按 引 用 传递 ， 否 则 按 值 传递 。 需 要 注意 的 是 ， 引 用 传递 可 避免 对 象 找 贝 ， 


被 修改 。 














2. 实 现 原 理 分 析 








提高 处 理 效率 ， 但 需要 确保 keyvalue 不 会 





ChainMapper/ChainReducer 实 现 的 关键 技术 点 是 修改 Mapper 和 Reducer 的 输出 流 ， 将 本 来 要 写 入 文件 的 输出 结果 重 定向 到 另外 一 
个 Mapper 中 。 在 3.3.4 节 中 提 到 ， 结 果 的 输出 由 OutputCollector 管 理 ， 因 而 ，ChainMapper/ChainReducer 需 要 重新 实现 一 个 























OutputCollector 完 成 数据 重 定向 功能 。 











Al 


管 链 式 作业 在 Map 和 Reduce 阶 段 添加 了 多 个 Mapper， 但 仍然 只 是 











个 MapReduce 作 业 ， 
































因而 只 能 有 一 个 与 之 对 应 的 JobConf 





对 象 。 然 而 ， 当 用 户 调用 addMapper 添 加 Mapper 时 ， 可 能 会 为 新 添加 的 每 个 Mapper 指 定 一 个 特有 的 JobConf， 为 





此 ，ChainMapper/ChainReducer 将 这 些 JobConf 人 对象 序列 化 后 ， 统 一 保存 到 作业 的 JobConf 中 。 图 


的 几 个 配置 选项 。 


表 3-3 3-27 中 实例 对 应 的 几 个 配置 选项 


配置 参数 


chain.mapper.mapper.config.0 


Ww 


chain.mapper.mapper.config. | 
chain.reducer.reducer.config.0 


chain.reducer.mapper.config.0 


当 链 式 作 业 开 始 执行 的 时 候 ， 首 先 将 各 个 Mapper 的 JobConf 对 象 反 序列 化 ， 并 构造 对 应 的 Mapper 和 Reducer 对 象 ， 添 加 到 数据 
结构 mappers (List<Mapper> %4!) 和 reducer (Reducer 类 型 ) 中 。ChainMapper 中 实现 的 map0O 函 数 如 下 ， 它 调用 了 第 一 个 Mapper， 











是 后 续 Mapper 的 “ 导 火 索 ”。 





3-27 中 的 实例 可 能 产生 如 表 3-3 所 示 





参数 值 


Mapper! Conf 序列 化 后 的 字符 串 
Mapper2Conf 序列 化 后 的 字符 串 
ReducerConf 序列 化 后 的 字符 串 
Mapper3Conf 序列 化 后 的 字符 串 














public void map (Object key, Object value, OutputCollector 
Reporter reporter) throws IOException{ 

Mapper mapper=chain.getFirstMap (); 

if (mapper! =null) { 


output, 


mapper.map (key, value, chain.getMapperCollector (0, output, reporter) , reporter) ; 
} 


} 








chain.getMapperCollector 返 回 一 个 OutputCollector 实 现 一 一 ChainOutputCollector， 它 的 collect 方 法 如 下 : 





public void collect (K key, V value) throws IOException{ 
if (nextMapperIndex<mappers.size()) { 

// 调 用 下 一 个 Mapper 

nextMapper.map (key, value, 

new ChainOutputCollector (nextMapperIndex, 
nextKeySerialization, 

nextValueSerialization, output, reporter) , 

reporter) ; 




















jelse{ 

// 如 果 是 最 后 一 个 Mapper， 则 直接 调用 真正 的 OutputCollector 
output.collect (key, value) ; 

} 






































3.5.3 Hadoop 工 作 流 引 擎 






































前 面 介绍 的 JobControl 和 ChainMapperChainReducer 仅 可 看 作 运 行 工作 流 的 工具 。 它 们 只 具备 最 简单 的 工作 流 引 擎 功能 ， 比 如 工 
作 流 描述 、 简 单 的 作业 调度 等 。 为 了 增强 Hadoop 支 持 工作 流 的 能 力 ， 在 Hadoop 之 上 出 现 了 很 多 开源 的 工作 流 引 擎 ， 主 要 可 概括 为 
PRA: 隐 式 工作 流 引擎 和 显 式 工作 流 引擎 。 






































隐 式 工作 流 引 擎 在 MapReduce 之 上 添加 了 一 个 语言 抽象 层 ， 人 允许 用 户 使 用 更 简单 的 方式 编写 应 用 程序 ， 比 如 SQL、 脚 本 语言 
等 。 这 样 ， 用 户 无 须 关 注 MapReduce 的 任何 细节 ， 降 低 了 用 户 的 学 习 成 本 ， 并 可 大 大 提高 开发 效率 。 典 型 的 代表 有 Hive IJ Pig 
和 CascadingB] 。 它 们 的 架构 如 图 3-29 所 示 ， 从 上 往 下 分 为 以 下 三 
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Ml 









































NS 











口 功能 描述 层 : 直接 面向 用 户 提供 了 一 种 简单 的 应 用 程 请 

















iS vk, in, Hivett HSQL, Pig 使 用 Pig Latin 脚 本 语言 ，Cascading 
























































口 作业 生成 器 : 作业 生成 器 主要 将 上 层 的 应 用 程序 转化 成 一 批 MapReduce 作 业 。 这 一 批 MapReduce 存 在 相互 依赖 关系 ， 实 际 上 
是 一 个 DAG。 











口 调度 引擎 : 调度 引擎 直接 构建 于 MapReduce 环 境 之 上 ， 将 作业 生成 器 生成 的 DAG 按 照 依赖 关系 提交 到 MapReduce 上 运行 。 








功能 描述 层 ( SQL, Pig 脚 本 ) 


作业 生成 如 


调度 引擎 

















图 3-29 隐 式 工作 流 引 擎 架构 图 




















显 式 工 作 流 引 擎 直接 面向 MapReduce 应 用 程序 开发 者 ， 提 供 了 一 种 作业 依赖 关系 描述 方式 ， 并 能 够 按照 这 种 描述 方式 进行 作业 


























调度 。 典 型 的 代表 有 Oozie 和 Azkapan[ 。 它 们 的 架构 如 图 3-30 所 示 ， 从 上 往 下 分 为 以 下 两 层 。 




















口 工作 流 描述 语言 : 工作 流 描述 语言 用 于 描述 作业 的 依赖 关系 。Oozie 采 用 了 XML， 而 Azkaban 采 用 了 keyvalue 格 式 的 文本 文 
件 。 需 要 注意 的 是 ， 这 里 的 作业 不 仅仅 是 指 MapReduce 作 业 ， 还 包括 Shell 命 令 、Pig 脚 本 等 。 也 就 是 说 ， 一 个 MapReduce 可 能 依赖 一 
A 
ki 






























































口 调度 引擎 : 同 隐 式 工作 流 引 擎 的 调度 引擎 功能 相同 ， 即 根据 作业 的 依赖 关系 完成 作业 调度 。 


工作 流 描述 语言 


调度 引擎 


MapReduce 运行 时 环境 














图 3-30 显 式 工作 流 引 擎 架构 图 

















表 3-4 对 比 了 显 式 工 作 流 引 擎 与 Hadoop 自 带 的 JopContro] 的 不 同 之 处 。 尽 管 它们 均 用 于 解决 Hadoop 工 作 流 调度 问题 ， 但 是 在 设计 
思路 、 使 用 方法 、 应 用 场景 等 方面 都 存在 明显 的 不 同 。 

































































R 3-4 显 式 工作 流 引 擎 与 JobControl 对 比 
i ET 
工作 流 描述 方式 有 专门 的 描述 语言 Java API 
执行 模型 client-side 
是 否 可 跟踪 运行 进度 不 可 以 


是 否 有 重 试 功能 有 ， 可 设置 作业 失败 重 试 机 制 没有 








( 续 ) 


ED ET 
依赖 关系 中 是 否 可 有 Pig 脚 本 、 可 以 不 可 以 ， 依 赖 关系 只 存在 于 使 用 
Shell 命令 等 Java 编写 的 MapReduce 作业 之 间 


[1] 可 参考 httpyhive.apache.org/ 相 关 文档 。 
[2] 可 参考 httpVpigapache.org/ 相 关 文 档 。 
[3] 可 参考 http//www.cascading.org/ 相 关 文 档 。 
[和 1 可 参考 httpy/sna-projects.conYazkaban/ 相 关 文 档 。 














3.6 小结 


MapReduce 编 程 模型 直接 决定 了 MapReduce 的 易 用 人 改 
MapReduce 编 程 模型 中 的 各 个 组 


从 整个 体系 结构 上 看 ， 整 个 编程 模型 位 于 应 用 程 








API， 第 二 层 构 建 于 Java API 之 上 ， 添 加 了 几 个 方便 月 





Java API 分 为 新 | 



























































j 性 。 本 章 从 简单 地 使 用 实例 、 设 计 原 理 以 及 调用 时 机 等 方面 介绍 了 

















件 。 



































程序 层 和 MapReduce 执 行 器 之 间 ， 可 以 分 为 两 层 














: 第 一 层 是 最 基本 的 Java 


昌 户 编写 复杂 的 MapReduce 程 序 和 利用 其 他 语言 编写 MapReduce 程 序 的 工具 。 











LAL 

























































































j 套 API。 新 API 在 旧 API 基 础 上 封装 而 来 ， 在 易 











用 性 和 扩展 性 方面 更 好 。 





























Wz. 














为 了 方便 用 户 采 用 非 Java 语 言 编写 MapReduce 程 
是 一 个 MapReduce 作 业 ， 











星 序 ，Hadoop 提 供 了 Hadoop Streaming 和 Hadoop Pipes 两 个 了 






































CA. EMA ER 


Xl 




















别 在 于 Java 语 言 与 非 Java 语 言 之 间 的 通信 机 制 。 














考虑 到 实际 应 

















J}, 
MapReduce 提 供 了 JobControl 和 ChainMappeVChainReducer 两 个 工具 


























j 户 有 时 不 只 是 编写 单一 的 MapReduce 作 业 ， 而 是 存在 复杂 依赖 关系 的 DAG 作 业 《〈 工 作 流 ) ，Hadoop 




















Yo 





本 部 分 内 容 
Hadoop RPC 框 架 解析 


作业 提交 与 初始 化 过 程 分 析 





JobTracker 内 部 实现 剖析 


TaskTracker 内 部 实现 剖析 


Task 运 行 过 程 分 析 





第 三 部 分 


第 4 章 Hadoop RPC 框 架 解析 





网 络 通信 模块 是 分 布 式 系 统 中 最 底层 的 模块 。 它 直接 支撑 了 上 层 分 布 式 环境 下 复杂 的 进程 
Communication, IPC) 逻辑 ， 是 所 有 分 布 式 系统 的 基础 。 远 程 
信 协 议 。 它 允许 运行 于 一 台 计 算 机 的 程 






































这 个 交互 作用 编程 。 

















作为 一 个 分 布 式 系统 ，Hadoop 实 现 了 自己 的 RPC 通 























由 于 RPC 大 大 简化 了 分 布 式 程序 开发 ， 






































RPC 实 际 上 是 分 布 式 计算 中 客户 机 /服务 器 (Client/Server) 模型 的 一 个 应 


公用 的 网 络 通信 模块 。 本 章 首 先 从 让 
应 用 

4.1 Hadoop RPC 框 架 概述 
点 


nyo 


口 透 明 性 : 











EA BT ke EBLE 


这 是 所 有 RPC 框 架 的 最 根本 特征 ， 




















过 程 调 






































序 调用 另 一 台 计 算 机 的 子 程序 ， 同 时 将 网 络 的 通信 
对 此 备 受 欢迎 。 









































用 





即 























应 感觉 到 其 间 涉 及 跨 机 器 间 的 通信 ， 而 是 感觉 像 是 在 执行 一 个 本 地 调用 。 





口 高 性 能 :Hadoop 各 个 系统 (如 HDFS, MapReduce) 均 采 
处 理 集群 中 所 有 Slave 发 送 的 服务 请 求 。 为 了 保证 Master 的 3 








来 自 多 个 Client 的 并 发 RPC 请 求 。 














口 可 控 性 : JDK 中 己 经 自前 


























Ņ H 


» ERIE 
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带 了 


个 RPC 框 架 














用 了 MasterSlave 结 构 。 









































RMI (Remote Method Invocation， 远 程 方法 调 


MapReduce 核 心 设计 篇 





H (Remote Procedure Call, RPC) 是 一 种 常 





间 通 信 (nter-Process 























j 的 分 布 式 网 络 通 






























































入 隐藏 起 来 ， 使 得 用 户 无 须 额外 地 为 


讶 协议， 它 是 上 层 多 个 分 布 式 子 系统 (如 MapReduce, HDFS, HBase 1 等 ) 


介绍 了 Hadoop RPC， 接 着 介绍 了 该 RPC 框 架 在 Hadoop MapReduce 中 的 














具有 以 下 几 个 特 





用 实例 。 对 于 Hadoop RPC 而 言 ， 它 

















为 考虑 到 RPC 是 Hadoop 最 底层 、 最 核心 的 模块 之 一 ， 保 记 








E 其 轻 量 级 、 高 性 





能 和 可 控 改 








] 户 可 控 之 处 太 少 〔( 如 网 络 连 接 、 超 时 和 缓冲 等 均 难以 定制 或 者 修改 》 呈 。 




















与 其 他 RPC 框 架 一 样 ，Hadoop RPC 主 要 分 为 四 个 部 分 ， 分 别 是 序列 化 层 、 函 数 























具体 实现 机 制 如 下 : 




















口 序 列 化 层 : 
JFK 


要 实现 Writable 接 












































主妇 


Rs 
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序列 化 层 的 主要 作 
] 户 请 求 中 的 参数 或 者 应 答 转化 成 字 节 流 以 便 跨 机 器 传输 。 第 3 章 
， 即 可 支持 对 象 序 列 化 与 反 序列 化 。 























`E 











y] 


中 已 经 提 到 ，Hadoop 自 





户 在 一 台 计算 机 的 程序 调用 另外 一 台 计算 机 上 的 子 程序 时 ， 用 户 


用 层 、 网 络 传输 层 和 服务 器 端 处 理 


j 是 将 结构 化 对 象 转 为 字 节 流 以 便于 通过 网 络 进行 传输 或 写 入 持久 存储 。 在 RPC 框 架 中， 























其 中 ，Master 实 际 上 是 一 个 RPC server， 它 负 
发 处 理 能 力 ，RPC server 应 是 一 个 高 性 能 服务 器 ， 能 够 高 效 地 处 理 








用 ) 。 之 所 以 不 直接 使 用 该 框 
FE 显 得 尤为 重 





要 ， 








PER 


而 RMI 过 于 是 


























Ct 











己 实现 了 序列 化 框架 ， 一 个 























口 函数 调用 层 : 函数 调用 层 的 主要 功能 是 定位 要 调用 的 函数 并 执行 该 函数 。HadoopRPC 采 用 Java 反 射 机 制 与 动态 代理 实 下 






































函数 调用 ， 具 体 参考 4.2.1 节 。 






































4.2.27. 











口 网 络 传输 层 : 网 络 传输 层 描述 了 Chent 与 Server 之 间 消 息 传输 的 方式 。Hadoop RPC 采 用 了 基于 TCP/ 耻 的 Socket 机 制 ， 有 具体 参 





























口服 务 器 端 处 理 框 架 : 服务 器 端 处 理 框 架 可 被 抽象 为 网 络 IO 模型 。 它 描述 了 客户 端 与 服务 器 端 | 






























































基于 Reactor 设 计 模 式 的 事件 驱动 /O 模 型 ， 具 体 参考 4.2.3 节 。 




















司 信息 交互 的 方式 。 它 的 设 


计 直 接 决 定 着 服务 器 端的 并 发 处 理 能 力 。 常 见 的 网 络 WO 模 型 有 阻塞 式 WJO、 非 阻塞 式 WO、 事 件 驱 动 WO 等 ， 而 Hadoop RPC 采 用 了 





Hadoop RPC 总 体 架 构 如 图 4-1 所 示 ， 自 下 而 上 可 分 为 两 层 。 第 一 层 是 一 个 基于 Java NIO (NewIO) 实现 的 客户 机 /服务 器 











(Client/Server) 通信 模型 。 其 中 ， 客 户 端 将 用 户 的 调用 方法 及 其 参数 封装 成 请 求 包 后 发 送 到 服务 器 端 。 










































































经 解 包 、 调 用 函数 、 打 包 结 果 等 一 系列 操作 后 ， 将 结果 返回 给 服务 器 端 。 为 了 增强 Server 端 的 扩展 性 









































E 和 并 发 处 理 能 





服务 器 端 收 到 请 求 包 后 ， 


力 ，Hadoop 


RPC 采 用 了 基于 事件 驱动 的 Reactor 设 计 模 式 ， 在 具体 实现 时 ， 用 到 了 JDK 提 供 的 各 种 功能 包 ， 主 要 包括 java.nio (NIO) 、 






























































java.langrefect〈 反 射 机 制 和 动态 代理 ) 、java.net (网络 编 程 库 ) 等 。 第 二 层 是 供 更 上 层 程序 直接 调 
即 为 客户 机 /服务 器 通信 模型 。 
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(Based On Reactor Model) 











Java NIO Java Reflection Java Net 
(java.nio.*) (java. lang. reflect.*) (java.net.*) 








图 4-1 Hadoop RPC 总 体 架 构图 




















[1] HBase RPC 在 Hadoop RPC 基 础 上 做 了 部 分 改 i 
[2] Doug Cutting 在 最 初 设计 Hadoop 时 是 这 样 描述 Hadoop RPC 设 计 动 机 的 。 








的 RPC 接 口 


这 些 接口 底层 





42 Java 基础 知识 












































在 本 节 中 ， 我 们 将 简要 介绍 Hadoop RPC 中 用 到 的 JDK 开 发 工具 包 中 的 一 些 类 。 了 解 和 掌握 这 些 类 的 功能 和 使 用 方法 是 深入 
学 习 Hadoop RPC 的 基础 。 这 些 类 主要 来 自 以 下 三 个 Java 包 : java.langreflect (反射 机 制 和 动态 代理 相关 类 ) 、java.net〔 网 络 编 程 
Æ) 和 javanio (NIO) 。 















































4.2.1 Java 反射 机 制 与 动态 代理 























T 











反射 机 制 是 Java 语 言 的 一 个 重要 特性 ， 它 允许 用 户 动 态 获 取 类 的 信息 和 动态 调用 对 象 的 方法 。 它 提供 的 类 及 类 对 应 的 功能 如 
Fs 





DClass 类 : 代表 一 个 Java 类 。 





DField 类 : 代表 Java 类 的 属性 。 

口 Method 类 : 代表 Java 类 的 方法 。 

口 Constructor 类 : 代表 Java 类 的 构造 函数 。 

DAmray 类 : 提供 了 动态 创建 数组 ， 以 及 访问 数组 元 素 的 静态 方法 。 


口 Proxy 类 以 及 InvocationHandler 接 口 : 提供 了 动态 生成 代理 类 以 及 实例 的 方法 。 
























































接 下 来 重点 介绍 Java 动 态 代 理 。 介 绍 Java 动 态 代 理 之 前 ， 先 介绍 “代理 ”这 一 概念 。 代 理 是 一 种 常用 的 设计 模式 ， 其 目的 是 为 
其 他 对 象 提供 一 种 代理 以 控制 对 这 个 对 象 的 访问 。 代 理 类 负责 为 委托 类 进行 预 处 理 〈 如 安全 检查 ， 权 限 检查 等 ) 或 者 执行 完 后 的 
后 续 处 理 〈 如 转发 给 其 他 代理 等 ) 。 













































































Java 动 态 代 理 机 制 的 实现 ， 使 得 开发 人 员 通 过 简单 地 指定 一 组 接口 及 委托 类 对 象 ， 便 能 动态 地 获得 代理 类 ， 这 大 大 简化 了 编 
写 代理 类 的 步骤 。 


















































要 学 习 Java 动 态 代 理 机 制 ， 需 要 首先 了 解 以 下 几 个 类 或 接口 。 


(1) java. langreflectProxy 









































这 是 Java 动 态 代 理 机 制 的 主 类 ， 它 提供 了 一 组 静态 方法 ， 用 于 为 一 组 接口 动态 地 生成 代理 类 及 其 对 象 。java.lang reflect.Proxy 
的 具体 实现 如 下 : 
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// 方 法 1: 获取 指定 代理 对 象 所 关联 的 调用 处 理 器 

static InvocationHandler getInvocationHandler (Object proxy) 

// 方 法 2: 获取 关联 于 指定 类 装载 器 和 一 组 接口 的 动态 代理 类 的 对 象 

static Class getProxyClass (ClassLoader loader, Class[]interfaces) 

// 方 法 3: 判断 指定 的 类 对 象 是 否 是 一 个 动态 代理 类 

static boolean isProxyClass (Class cl) 

// 方 法 4: 为 指定 类 装载 器 、 一 组 接口 及 调用 处 理 器 生成 动态 代理 类 实例 

static Object newProxyInstance (ClassLoader loader, Class[]interfaces, InvocationHandler h) 







































































(2) java. lang.reflect.InvocationHandler 



































这 是 调用 处 理 器 接口 。 它 定义 了 一 个 invoke 方 法 ， 用 于 处 理 在 动态 代理 类 对 象 上 的 方法 调用 。 通 常 开发 人 员 需 实现 该 接口 ， 




















并 在 invoke 方 法 中 实现 对 委托 类 的 代理 访问 。invoke 方 法 声明 如 下 : 














// 该 方法 负责 处 理 动态 代理 类 上 的 所 有 方法 调用 。 包 含 三 个 参数 ， 分 别 表示 代理 类 实例 
// 被 调用 的 方法 对 象 、 调 用 参数 。 调 用 处 理 器 根据 这 三 个 参数 进行 预 处 理 或 分 派 到 委托 类 实例 上 执行 



















































































Object 


invoke (Object proxy, Method method, Object []Jargs) 








一 个 典型 的 动态 代理 创建 对 象 的 过 程 可 分 为 以 下 4 个 步骤 : 


步 又 1 


























通过 实现 InvocationHandler 接 口 创建 自己 的 调用 处 理 器 : 























InvocationHandler handler=new InvocationHandlerImpl (.....) ; 





步 又 2 





通过 为 Proxy 类 指定 ClassLoader 对 象 和 一 组 inter 人 ce 创建 动态 代理 类 : 





Class clazz=Proxy.getProxyClass (classLoader, new Class[] {....}) ; 





步骤 3 














通过 反射 机 制 获 取 动 态 代理 类 的 构造 函数 ， 其 参数 类 型 是 调用 处 理 器 接口 类 型 : 























Constructor constructor=clazz.getConstructor (new Class[]{InvocationHandler.class}) ; 





步骤 4 


通过 构造 函数 创建 动态 代理 类 实例 ， 此 时 需 将 调用 处 理 器 对 象 作 为 参数 被 传 入 : 











Interface Proxy= (Interface) constructor.newInstance (new Object[]{handler}) ; 





为 了 简 














化 对 象 创建 过 程 ，Proxy 类 中 的 newInstance 方 法 封装 了 步骤 2 一 步骤 4， 只 需 两 步 即 可 完成 代理 对 象 的 创建 。 
1 给 出 一 个 详细 的 动态 代理 创建 对 象 的 实例 : Server 类 提供 了 计算 整 型 数 相 加 和 相 减 的 两 个 方法 ， 用 户 可 直接 通过 









































问 这 两 个 方法 (类 似 于 RPC Client) 。 


代码 清 




















青 单 4-1 Java 动态 代理 示例 程 请 








代码 清单 4- 














GENRE 





WAV 

















interface CalculatorProtocol{// 定 义 一 个 接口 协议 


public 
public 








int add (int a, int b) ; // 两 个 数 相 加 
int subtract (int a, int b); // 两 个 数 相 减 








class Server implements CalculatorProtocol{// 实 现 接 口 协 议 











public int add (int a, int b) { 
return ath; 

public int subtract (int a, int b) { 
return a-b; 

/ /实现 调用 处 理 器 接 

















class CalculatorHandler implements InvocationHandler{ 
private Object objOriginal; 


public 


CalculatorHandler (Object obj) { 





this.objOriginal=ob}; 


} 

public 
throws 
// 可 添 
Object 
// 可 添 
return 


} 


} 

// 测 试 
public 
public 


























Object invoke (Object proxy, Method method, Object[]args) 
Throwable { 


0 一 些 预 处 理 


result=method.invoke (this.objOriginal, args) ; 


[一 些 后 续 处 理 


result; 


例 
class DynamicProxyExample{ 
static void main (String[Jargs) { 


CalculatorProtocol server=new Server(); // 创 建 Server 

InvocationHandler handler=new CalculatorHandler (server) ; 

CalculatorProtocol client= (CalculatorProtocol) Proxy.newProxyInstance (server. 
getClass().getClassLoader(), server.getClass().getInterfaces(), handler) ; 








// 创 建 一 





个 Client 


int r=client.add (5, 3); 


System. 


out.printlin ("5+3="4+r) ; 


r=client.subtract (10, 2) ; 


System. 
} 
} 


out.println ("10-2="4+r) ; 





4.2.2 Java 网 络 编程 




















通常 ，Java 网 络 程序 建立 在 TCP/ 下 协议 基础 上 ， 致 力 于 实现 应 用 层 。 传 输 层 向 应 用 层 提 供 了 套 接 字 Socket 接 口 ， 它 封装 了 下 
层 的 数据 传输 细节 ; 应 用 层 的 程序 可 通过 Socket 与 远程 主机 建立 连接 和 进行 数据 传输 。 








JDK 提 供 了 3 种 套 接 字 类 : java.netSocket、java.net'ServerSocket 和 java.net DatagramSocket。 其 中 ，java.netSocket 和 
java.net.ServerSocket 类 建立 在 TCP 协 议 基础 上 ， 而 java.net.DatagramSocket 类 则 建立 在 UDP 协 议 基础 上 。Java 网 络 程序 均 采 用 客户 机 / 
服务 器 通信 模式 。 下 面 介 绍 如 何 使 用 java.net Socket 和 java.net ServerSocket 编 写 客户 端 和 服务 器 端 程序 。 
































如 图 4-2 所 示 ， 编 写 一 个 客户 端 程序 需要 以 下 3 个 步骤 。 





服务 器 进程 


创建 ServerSocket 对 象 ; 


serverSocket= new 
ServerSocket(port) 


监听 客户 端 进程 





创建 客户 端 Socket: 


监听 来 自 客户 端的 请 求 发 起 连接 


soc= new 
soc=serverSocket accept() 


Socket(serverHost, port) 





构造 数据 输入 流 ， 用 以 接收 数据 : 构造 数据 输入 流 , 用 以 接收 数据 : 





断 开 连接 : 断 开 连接 : 
soc.close() soc.close() 








图 4-2 Java 客 户 端 /服务 器 端 通信 模型 




















步骤 1 创建 客户 端 Socket: 








Socket soc=new Socket (serverHost, port) ; 











其 中 ，serverHost 为 服务 器 端的 hosb port 为 服务 器 端的 监听 端口 号 。 一 旦 Socket 创 建成 功 ， 则 表示 客户 端 连 接 服务 器 成 功 。 

















= 


步骤 2 ”创建 输出 、 输 入 流 以 向 服务 器 端 发 送 数据 和 从 服务 器 端 接收 数据 : 





// 构 造 数据 输入 流 ， 用 以 接收 数据 











DataInputStream in=new DataInputStream (soc.getInputStream()) ; 


/ /构造 数据 输出 流 ， 用 以 发 送 数 据 





























DataOutputStream out=new DataOutputStream (soc.getOutputStream()) ; 





// 应 用 程序 发 送 和 接收 数据 




















步骤 3 WIT ERE: 





soc.close(); 








如 图 4-2 所 示 ， 编 写 一 个 服务 器 端 程序 需要 以 下 4 个 步骤 。 





步骤 1 创建 ServerSocket 对 象 : 





ServerSocket serverSocket=new ServerSocket (port) ; 

















其 中 ，port 为 服务 器 端的 监听 端口 号 。 当 客户 端 向 服务 器 端 建立 连接 时 ， 需 要 知道 该 端口 号 。 创 建 ServerSocket 对 象 成 功 后 ， 
操作 系统 将 把 当前 进程 注册 为 服务 器 进程 。 























步骤 2 ”监听 端口 号 ， 等 待 新 连接 到 达 : 








Socket soc=serverSocket.accept (); 








运行 函数 acceptO 后 ，ServerSocket 对 象 会 一 直 处 于 监听 状态 ， 等 待 客户 端的 连接 请 求 。 一 旦 有 客户 端 请 求 到 达 ， 该 函数 会 返 
回 一 个 Socket 对 象 ， 该 Socket 对 象 与 客户 端 Socket 对 象形 成 一 条 通信 链 路 。 


























步骤 3 创建 输出 、 输 入 流 以 向 客户 端 发 送 数据 和 从 客户 端 接 收 数据 。 此 处 的 程序 和 客户 端的 一 样 ， 故 不 再 更 述 。 

















步骤 4 断 开 连接 。 此 处 的 程序 和 客户 端的 一 样 ， 故 不 再 赣 述 。 















































在 ClentServer 模 型 中 ，Server 往 往 需要 同时 处 理 大 量 来 自 Client 的 访问 请 求 ， 因 此 Server 端 需 采用 支持 高 并 发 访问 的 架构 。 一 
种 简单 而 又 直接 的 解决 方案 是 "one-thread-per-connectiom”。 这 是 一 种 基于 阻塞 式 IO 的 多 线程 模型 ， 如 图 4-3 所 示 。 在 该 模型 
中 ，Server 为 每 个 Client 连 接 创建 一 个 处 理 线程 ， 每 个 处 理 线程 阻塞 式 等 待 可 能 到 达 的 数据 ， 一 旦 数据 到 达 ， 则 立即 处 理 请 求 、 返 
回 处 理 结果 并 再 次 进入 等 待 状态 。 由 于 每 个 Client 连 接 有 一 个 单独 的 处 理 线程 为 其 服务 ， 因 此 可 保证 良好 的 响应 时 间 。 但 当 系 统 
负载 增 大 并 发 请 求 增多 ) 时 ，Server 端 需要 的 线程 数 会 增加 ， 这 将 成 为 系统 扩展 的 瓶颈 所 在 。 






































































































































Zl 












































图 4-3 旧 IO 模 型 ， 多 个 线程 阻塞 等 待 客 户 端 请 求 














4.2.3 Java NIO 


1. 简 介 




















自从 JSE 1.4 版 本 以 来 ，JDK 发 布 了 全 新 的 WO 类 库 ， 简 称 NIO (NewIO) 。 它 不 但 引入 了 全 新 的 高 效 的 IO 机 制 ， 同 时 引入 了 基于 Reactor 
设计 模式 的 多 路 复 用 异步 模式 。NIO 的 包 中 主要 包含 了 以 下 几 种 抽象 数据 类 型 。 










































































口 Channel〈 通 道 ) : NIO 把 它 支持 的 IO 对 象 抽象 为 Channel。 它 模拟 了 通信 连接 ， 类 似 于 原 IJO 中 的 流 〈Stream) ， 用 户 可 以 通过 它 读 取 和 
写 入 数据 。 目 前 已 知 的 实例 类 有 SocketChannel、ServerSocketChannel、DatagramChannel、FileChannel 等 。 

































































口 Buffer (缓冲 区 ) : BufRr 是 一 块 连续 的 内 存 区 域 ， 一 般 作 为 Channel 收 发 数据 的 载体 出 现 。 所 有 数据 都 通过 Buffer 对 象 来 处 理 。 用 户 永 远 
不 会 将 字 节 直接 写 入 通道 中 ， 相 反 ， 需 将 数据 写 入 包含 一 个 或 者 多 个 字 节 的 缓冲 区 ， 同 样 ， 也 不 会 直接 从 通道 中 读 取 字 节 ， 而 是 将 数据 从 通 
道 读 入 缓冲 区 ， 再 从 缓冲 区 获取 这 个 字 节 。 









































































































































口 Selector (选择 器 ) : Selector 类 提供 了 监控 一 个 或 多 个 通道 当前 状态 的 机 制 。 只 要 Channel 向 Selector 注 册 了 某 种 特定 事件 ，Selector 就 会 监 
听 这 些 事件 是 否 会 发 生 ， 一 旦 发 生 某 个 事件 ， 便 会 通知 对 应 的 Channel。 使 用 选择 器 ， 借 助 单一 线程 ， 就 可 对 数量 庞大 的 活动 JO 通道 实施 监控 


和 维护 ， 具 体 如 图 4-4 所 示 。 
Socket Socket | 
SocketChannel SocketChannel | SocketChannel 
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图 4-4 新 IO 模型 ， 单 个 线程 阻塞 等 待 客户 端 请 求 
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(1) Bufer 相 关 类 





























java. nio 包 公开 了 Bufler API， 使 得 Java 程 序 员 可 以 直接 控制 和 运用 缓存 区 











又 
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缓冲 区 包含 以 下 3 个 属性 。 












































Dcapacity 缓冲 区 的 末 位 值 。 它 表明 了 缓冲 区 最 多 可 以 保存 多 少数 据 。 








Dlimit， 表 示 缓 冲 区 的 当前 存放 数据 的 终点 。 不 能 对 超过 limit 的 区 域 进行 读 写 数据 。 














Oposition: 下 一 个 读 写 单元 的 位 置 。 每 次 读 写 缓冲 区 时 ， 均 会 修改 该 值 ， 为 下 一 次 读 写 数据 做 准备 。 




















这 三 个 属性 的 大 小 关系 是 capacity>limit>position>0。 
































如 图 4-5 所 示 ，BufRer 有 两 种 不 同 的 工作 模式 一 一 写 模 式 和 读 模式 。 在 写 模式 下 ，lintt 与 capacity 相 同 ，position 随 着 写 入 数据 增加 ， 逐 渐 增 加 
到 lmit， 因 此 ，0 到 position 之 间 的 数据 即 为 已 经 写 入 的 数据 ;在 读 模式 下 ，Jlimit 初 始 指向 position 所 在 位 置 ，position 随 着 数据 的 读 取 ， 逐 渐 增 加 到 
jnmit， 则 0 到 position 之 间 的 数据 即 为 已 经 读 取 的 数据 。 函 数 好 0 可 将 写 模 式 转化 为 读 模 式 ， 其 他 常用 函数 如 下 。 

































































口 clear0: 重 置 Bufer， 即 将 limt 设 为 capacity， 而 position 为 0。 











QhasRemmining()/remmaining): 分 别 用 于 判断 BufRr 是 否 有 剩余 空间 和 获取 BufRr 剩 余 空 间 ， 其 中 剩余 空间 大 小 即 为 jnmnitrposition。 




















U capacity()/limitO/position0: 分 别 用 于 获取 Buffer 的 capacity、linnt 和 position 属 性 的 值 。 























Olimit Cnt newLimit) /position (newPosition) : 分 别 用 于 设置 Buffer 的 lmnt 和 position 属 性 。 




































Buffer- Write mode Buffer -Read mode 
position 一 一 一 > 
position ——> limit ) 








capacity ——> 





图 4-5 BufRr 的 写 模式 和 读 模式 









































java. nio.Buffer 是 一 个 抽象 类 ， 不 能 被 实例 化 。 除 boolean 类 型 外 ， 每 种 基本 类 型 都 有 对 应 的 具体 的 Bufer 类 ， 其 中 最 基本 、 最 常用 的 是 
ByteBuffer。 它 存放 的 数据 单元 是 字 节 。 它 并 没有 提供 直接 的 构造 函数 ， 而 是 提供 了 以 下 两 个 静态 工厂 方法 : 






















































































// 方 法 1 创建 一 个 Heap Buffer， 其 空间 分 配 在 JVM 的 堆 上 ， 和 其 他 对 象 一 样 ， 由 GC 回收 
static ByteBuffer allocate (int capacity) 
/* 方 法 2 创建 一 个 Direct Buffer， 并 通过 底层 的 JNI 调 用 C Runtime Time 的 malloc 函 数 分 配 空 
间 ， 可 看 作 * 内 核 空 间 ”。 其 创建 代价 比 Heap Buffer 大 ， 但 更 高 效 。*/ 

static ByteBuffer allocateDirect (int capacity) 





















































每 个 具体 类 均 提 供 了 一 系列 读 写 Buffer 的 函数 ， 想 进一步 了 解 的 读者 可 查看 JDK Document!!! 。 








(2) Channel 相 关 类 

















java. nio 提 供 了 多 种 Channel] 实 现 ， 其 中 ， 最 常用 的 是 以 SelectableChanne] 为 基 类 的 通道 。SelectableChanne] 是 一 种 支持 阻塞 JO 和 非 阻塞 IO 的 
通道 ， 它 的 主要 方法 如 下 : 




















DQ SelectableChannel configureBlocking (boolean block) throws IOException. 











O 〇 作用 : 设置 当前 SelectableChanne! 的 阻塞 模式 。 





























〇 参数 含义 : block 表 示 是 否 将 SelectableChannel 设 置 为 阻塞 模式 。 














O 





回 值 : SelectableChannel 对 象 本 身 的 引用 ， 相 当 于 “Yeturn this”. 
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U SelectionKey register (Selector sel, int ops) throws ClosedChannelException. 














O 〇 作用 : 将 当前 Channep 注 册 到 一 个 Selector 中 。 














〇 参数 含义 : se 表示 要 注册 的 Selector; ops 表 示 注 册 事 件 。 








〇 返回 值 ， 与 注册 Channel 关 联 的 SelectionKey 对 象 ， 用 于 跟踪 被 注册 事件 。 











SelectableChanne] 的 两 个 子 类 是 ServerSocketChannel 和 SocketChannel， 它 们 分 别 是 ServerSocket 和 Socket 的 替代 类 。 



































ServerSocketChannel 主 要 用 于 监听 TCP 连 接 ， 它 提供 了 以 下 3 个 最 常用 的 方法 。 























口 ServerSocketChannel open()throws IOException: 用 于 创建 ServerSocketChannel 的 静态 工厂 方法 。 其 返回 的 ServerSocketChannel 对 象 没 有 与 任 











何 本 地 端口 号 绑 定 ， 处 于 阻塞 状态 。 


口 SocketChannel acceptOthrows IOException: 接收 来 


































































































自 客户 端的 连接 。 当 ServerSocketChannel 设 置 为 阻塞 模式 时 ， 该 函数 一 直 会 处 于 阻塞 状 




















态 ， 直 到 有 客户 











ysk 











MAREA Se UH AS 6 EAA 
































SE 


崩 请 求 出 现 ， 则 会 返回 一 个 处 于 阻塞 模式 的 SocketChannel。 














口 ServerSocket socket): 返回 一 个 与 ServerSocketChannel 关 联 的 ServerSocket 对 象 。 注 意 ， 每 个 ServerSocketChannel 对 象 都 有 一 个 ServerSocket 
对 象 与 之 关联 。 


SocketChannelI 可 看 作 Socket 的 替代 类 ， 


和 socket(0 方 法 〈 返 回 与 SocketChannel 关 联 的 Socket 对 象 ) 。 


口 boolean connect (SocketAddress remote) throws IOException: 连接 Channel 对 应 的 Socket。 如 果 SocketChannel 处 于 阻塞 模式 ， 则 直接 返回 结 


R: 否则， 进入 阻塞 状态 ， 直 到 连接 成 功 或 者 抛 出 异常 。 


int read (ByteBuffèr dst) throws IOException: 将 当 
FE 阻塞 模式 下 ， 
到 达 输 入 流 末 尾 或 者 抛 出 异常 。 该 函数 的 返回 值 为 实际 读 取 的 数据 字 节 数 。 


E: 在 





ByteBufer 被 填 满 ， 






























































前 Channel 中 的 数据 读 取 到 ByteBuffer 中 。 




















但 功能 比 Socket 更 加 强大 。 同 ServerSocket-Channel 类 似 ， 它 提供 了 更 态 工厂 方法 open( (创建 对 象 ) 


























方法 如 下 。 


它 的 其 他 常 















































U 


在 阻塞 和 非 阻 塞 模式 下 ， 该 函数 实现 方式 不 

















遵从 能 读 取 多 少数 据 就 读 取 多 少数 据 的 原则 ， 总 是 立即 返回 结果 ; 而 在 阻塞 模式 下 ， 将 尝试 一 直 读 取 数 据 ， 直 到 





















































Dint write (ByteBuffer src) throws IOException: 将 ByteBufRr 中 的 数据 写 入 Channel 中 。 与 Tfead 函 数 类 似 ， 在 阻塞 模式 和 非 阻塞 模式 下 ， 该 函 
数 实现 方式 不 同 : 在 非 阻 塞 模 式 下 ， 遵 从 能 输出 多 少数 据 
写 入 Channel， 如 果 底 














底层 实现 中 使 用 了 Direct Buffer 暂 时 对 数据 进行 
Buffer 大 小 不 够 ， 则 再 创建 一 个 更 大 的 Direct Buffer, H142 
































时 就 输出 多 少数 据 的 原则 ， 总 是 立即 返回 结果 ; 在 阻塞 模式 下 ， 会 尝试 着 将 所 有 数据 




















层 的 网 络 缓冲 区 容纳 不 了 这 么 多 全 




















节 ， 则 会 阻塞 至 可 写 入 所 有 数据 或 者 抛 出 异常 。 


























调用 write 方法 将 一 个 Heap Buffer 中 的 数据 写 入 某 个 Channel (或 者 调用 read 方 法 将 Channel 中 的 数据 读 入 一 个 Heap Buffer 对 象 ) 时 ，Sun Java 
缓冲 ， 大 体 步 又 为 JVM 初 始 创建 一 个 固定 大 小 的 Direct BufRr， 并 将 数据 写 入 该 BufREr， 如 果 






























































升 。 为 


代码 清 


青 单 4-2 ”将 ByteBuffer 中 的 数据 以 chunk 为 六 




















前 的 Direct BufRr 中 的 内 容 复制 到 新 的 Direct Buffer 中 ， 依 此 类 推 ， 直 到 将 数据 全 部 写 






































明显 ， 该 过 程 涉及 大 量 内 存 复制 操作 ， 会 明显 降低 性 能 。 此 外 ， 由 于 Direct Buffer 所 占 内 存 不 会 被 马上 释放 ， 因 此 会 造成 内 存 使 用 又 


























解决 该 问题 ， 可 将 写 入 的 数据 分 成 固定 大 小 《〈 比 如 8KB) 的 chunk， 并 以 chunk 为 单位 写 入 Direct Buffer 由， 代码 如 代码 清单 4-2 所 示 。 


和 位 写 入 Direct Buffer 





int 


ByteBuffer buffer) throws IOException{ 


// 如 





NIO BUFFER LIMIT=8*1024; //chunk 大 小 : 8KB 
// 将 Buffer 中 的 数据 写 入 Channel 中 ， 其 中 Channel 处 于 非 阻塞 模 式 


int channelWrite (WritableByteChannel channel, 

















果 缓 冲 区 中 的 数据 小 于 8KB， 则 直接 写 到 Channe1 中 ， 和 否则 以 chunk 为 单位 写 入 











return (buffer.remaining()<=NIO BUFFER LIMIT) 


channel.write (buffer) : 


} 
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channeliIO (null, channel, buffer) ; 


private static int channelIO (ReadableByteChannel readCh, 
WritableByteChannel writeCh, 
ByteBuffer buf) throws IOException { 
int originalLimit=buf.limit (); 

int initialRemaining=buf.remaining(); 


int 


ret=0; 


while (buf.remaining()>0) { 
try{ 


int ioSize=Math.min (buf.remaining(), 


buf.limit (buf.position()+ioSize) ; 


ret= (readCh==null) ?writeCh.write (buf) : 
IERT, writeR# readh BOY MA MBit KX iia 
可 值 为 实际 写 入 或 者 读 取 的 数据 


// 非 
// 返 


NIO_ BUFFER LIMIT) ; 


readCh.read (buf) ; 














SAREE 

















if (ret<ioSize) { 
break; 


} 
}finally{ 
buf.limit (originalLimit) ; 


} 
} 


int nBytes=initialRemaining-buf.remaining(); 
return (nBytes>0) ?nBytes: ret; 


} 








图 4-6 阐 释 了 按照 代码 清单 42 中 的 逻辑 ，ByteBufer 中 的 数据 写 入 Channel 过 程 中 ， 其 内 部 各 个 居 

















性 的 变化 情况 。 
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4-6 将 ByteBufRr 中 的 数据 以 chunk 为 单位 写 入 Channe] 过 程 


position + position 
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(3) Selector? 














Selector 可 监听 ServerSocketChannel 和 SocketChanne 了 注册 的 特定 事件 ， 一 旦 某 个 事件 发 生 ， 则 会 通知 对 应 的 Channel。SelectableChanne] 的 
iegister( 方 法 负责 注册 事件 ， 该 方法 返回 一 个 SelectionKey 对 象 ， 该 对 象 即 为 用 于 跟踪 这 些 注 册 事件 的 句柄 。 









































Selector 中 常用 的 方法 如 下 。 














static Selector open): 一 个 静态 工厂 方法 ， 可 用 于 创建 Selector 对 象 。 














Dint select (longtimeout) : 该 方法 等 待 并 返回 发 生 的 事件 。 一 旦 某 个 注册 的 事件 发 生 ， 就 会 返回 对 应 的 SelectionKey 的 数目 ， 和 否则 ， 一 直 
处 于 阻塞 状态 ， 直 到 以 下 四 种 情况 之 一 发 生 : 至 少 一 个 事件 发 生 ， 其 他 线程 调用 了 Selector 的 wakeup0 方 法 ， 当 前 执行 Select0 方 法 的 线程 被 中 
断 ， 超 出 等 待 时 间 timeout， 如 果 不 设置 等 待 时 间 ， 则 表示 永远 不 会 超时 。 


















































口 set selectedKeys(): Selector 捕 获 的 已 经 发 4 











IT 
aint 
Mj 


EXT HI SelectionKey42 4. 



































U Selector wakeup(): 立刻 唤醒 当前 处 于 阻塞 状态 的 Selector。 常 见 应 用 场景 是 ， 线 程 A 调用 Selector 对 象 的 select0 方 法 ， 阻 塞 等 待 某 个 注册 
件 发 生 ， 线 程 B 通 过 调用 wakeup0 函 数 可 立刻 唤醒 线程 A， 使 其 从 select0 方 法 中 返回 











aint 
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(4) SelectionKey 类 


























ly 








ServerSocketChanne| 或 SocketChannel 通 过 register0 方 法 向 Selector 注 册 事 件 时 ，register0 方 法 会 创建 一 个 SelectionKey 对 象 ， 用 于 跟踪 注册 
件 。 在 SelectionKey 中 定义 了 4 种 事件 ， 分 别 用 以 下 4 个 整 型 常量 表示 。 


lint 
































口 SelectionKey. OP_ACCEPT: 接收 (accept) 连接 就 绪 事 件 ， 表 示 服 务 器 端 接收 到 了 客户 端 连接 。 

















OSelectionKey. OP CONNECT: 连接 就 绪 事 件 ， 表 示 客 户 端 与 服务 器 端的 连接 已 经 建立 成 功 。 


























QSelectionKey. OP READ; 读 就 绪 事 件 ， 表 示 通 道中 已 经 有 了 可 读数 据 ， 可 执行 读 操 作 了 。 








OSelectionKey. OP_ WRITE: 写 就 绪 事 件 ， 表 示 可 向 通道 中 写 入 数据 了 。 




















通常 而 言 ，ServerSocketChannel 对 象 向 Selector 中 注册 SelectionKey.OP_ACCEPT 事 件 ， 而 SocketChannel 对 象 向 Selector 中 注册 
SelectionKeyOP CONNECT、SelectionKey.OP_READ 和 SelectionKey.OP_WRITE 三 种 事件 。 


























SelectionKey 类 中 比较 重要 的 方法 如 下 。 





口 Object attach (Object ob) : 为 当前 SelectionKey 关 联 一 个 Object 类 型 的 对 象 。 每 个 SelectionKey 只 能 关联 一 个 对 象 。 








口 Object attachment): 获取 当前 SelectionKey 关 联 的 Object 对 象 。 





u 


U SelectableChannel channel): 返 








与 当前 SelectionKey 关 联 的 SelectableChannel 对 象 。 




















(5) 应 用 实例 一 一 echoServer 






































echoServer 是 一 个 采用 NIO 编 写 的 服务 器 。 它 接收 客户 端 发 送 过 来 的 字符 串 ， 不 经 任何 处 理 直 接 再 ; 








给 客户 端 。 
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echoServer 由 五 个 程序 段 组 成 ， 分 别 如 下 。 











1) 初始 化 : 





public Selector initSelector()throws IOExceptiont{ 
address=new InetSocketAddress (bindAddress, port) 

// 创 建 一 个 ServerSocketChanne1， 并 将 之 设 为 非 阻塞 模式 
acceptChannel=ServerSocketChannel .open (); 
acceptChannel.configureBlocking (false) ; 

// 将 Server Socket 绑 定 到 aqqress 地 直上， 并 设置 监听 队列 长 度 
acceptChannel.socket () .bind (address, backlogLength) ; 
Selector selector=Selector.open (); 
// 向 Selector 注 册 ServerSocketChannel， 注 册 事 件 为 SelectionKey .OP_ACCEPT 
acceptChannel.register (selector, SelectionKey.OP_ACCEPT) ; 

return selector; 


} 






























































2) 监听 客户 端 


aint 


和 件 ， 并 调用 对 应 事件 处 理 函 数 : 

















aE 





public void run(){ 












































while (true) { 

Selectionkey key=null; 

try{ 

selector.select (); // 处 于 阻塞 状态 ， 直 到 有 新 事件 发 生 
Iterator<Selectionkey>iter=selector.selectedKeys () .iterator (); 
while (iter.hasNext ()) { 

key=iter.next (); 

iter. remove (); 

if (! key.isValid()) { 

continue; 

} 

if (key.isAcceptable() ) { 


doAccept (key) ; // 新 客户 端 ne 
jelse if (key.isReadable ( 
receive (key) ; De 
}else if (key.isWwritable ()) { 
send (key) ; // 向 客户 端 发 送 数据 

} 

key=null; 





} 
}catch (Exception e) {} 
} 
} 











3) 接受 新 客户 端 连接 请 求 : 





private void doAccept (SelectionKey key) throws IOException{ 
ServerSocketChannel serverSocketChannel= (ServerSocketChannel) key.channel (); 
// 接 受 连接 请 求 ， 并 将 之 设置 为 非 阻塞 模式 

SocketChannel socketChannel=serverSocketChannel.accept (); 
socketChannel.configureBlocking (false) ; 

// 将 新 的 Socketchannel 注 册 到 Selector 中 ,一旦 有 需要 读 或 者 写 的 数据 ， 就 会 通知 相应 的 程序 
SelectionKey clientKey= 
socketChannel.register (this.selector, SelectionKey.OP_READ) ; 
ByteBuffer buffer=ByteBuffer.allocate (8192) ; 
clientKey.attach (buffer) ; // 关 联 一 个 缓冲 区 
} 














4) 处 理 读 数据 请 求 : 





private void receive (SelectionKey key) throws IOException{ 
SocketChannel socketChannel= (SocketChannel) key.channel (); 
ByteBuffer readBuffer= (ByteBuffer) key.attachment (); 





socketChannel.read (readBuffer) ; 

if (numRead>0) { 

readBuffer.flip(); 

key. interestOps (SelectionKey.OP WRITE) ; // 切 换 至 OP_WRITE 
} 

} 








5) 处 理 写 数据 请 求 : 





private void send (SelectionKey key) throws IOException{ 
SocketChannel socketChannel= (SocketChannel) key.channel (); 
ByteBuffer writeBuffer= (ByteBuffer) key.attachment (); 
socketChannel.write (writeBuffer) ; 

if (writeBuffer.remaining()==0) {// 写 完成 后 ， 切 换 至 SelectionKey.OP_RERAD 
writeBuffer.clear(); 

key.interestOps (SelectionKey.OP_ READ) ; 

} 

} 








[1] http//docs. oracle.conyjavase/1.4.2/docs/guide/nio/ 
[2] 可 参考 httpsVissues.apache.orgyjira/browse/HADOOP-4797 下 的 相关 文档 。 





4.3 Hadoop RPC 基 本 框架 分 析 


4.3.1 RPC 基 本 概念 





RPC 是 一 种 通过 网 络 从 远程 计算 机 上 请 求 服务 ， 但 不 需要 了 解 底层 网 络 技术 的 协议 。RPC 协 议 假定 某 些 传输 协议 已经 存在 ， 如 TCP 


























或 UDP 等 ， 并 通过 这 些 传输 协议 为 通信 程序 之 间 传 递 访问 请 求 或 者 应 答 信 息 。 在 OSI 网 络 通信 模型 中 ，RPC 跨 越 了 传输 层 和 应 用 层 。 


























RPC 使 得 开发 分 布 式 应 用 程序 更 加 容易 由。 

















RPC 通 常 采用 客户 机 /服务 器 模型 。 请 求 程序 是 一 个 客户 机 ， 而 服务 提供 程序 则 是 一 个 服务 器 。 一 个 典型 的 RPC 框 架 主要 包括 以 下 





几 个 部 分 。 





























口 通信 模块 : 两 个 相互 协作 的 通信 模块 实现 请 求 -应 答 协议 。 它 们 在 客户 机 和 服务 器 之 间 传 递 请 求 和 应 答 消息 ， 
进行 任何 处 理 。 




















一 般 不 会 对 数据 包 














请 求 -应 答 协议 的 实现 方式 有 两 种 ， 分 别 是 同步 方式 和 异步 方式 。 如 图 4-7 所 示 ， 同 步 模式 下 客户 端 程序 一 直 阻 塞 到 服务 嚣 端 发 送 的 




















应 答 请 求 到 达 本 地 ， 而 异步 模式 则 不 同 ， 客 户 端 将 请 求 发 送 到 服务 器 端 后 ， 不 必 等 待 应 答 返 回 ， 可 以 做 其 他 事情 ， 
请 求 后 ， 主 动 通知 客户 端 。 在 高 并 发 应 用 场景 中 ， 一 般 采 用 异步 模式 以 降低 访问 延迟 和 提高 带宽 利用 率 。 







































































待 服务 器 端 处 理 完 


























口 Stub 程 序 : 客户 端 和 服务 器 端 均 包含 Stub 程 序 ， 可 将 之 看 作 代理 程序 。 它 使 得 远程 函数 调用 表现 的 跟 本 地 调 | 























一样 ， 对 用 户 程序 






























































及 务 器 端 。 此 外 ， 



































和 编码 应 答 结果 的 返回 值 。 

















完全 透明 。 在 客户 端 ， 它 表现 的 就 像 一 个 本 地 程序 ， 但 不 直接 执行 本 地 调用 ， 而 是 将 请 求 信息 通过 网 络 模 块 发 送 给 有 
当 服 务 器 端 发 送 应答 后 ， 它 会 解码 对 应 结果 。 在 服务 器 端 ，Stub 程 序 依次 进行 以 下 处 理 : 解码 请 求 消息 中 的 参数 、 调 用 相应 的 服务 过 程 



































口 调度 程序 ， 调度 程序 接收 来 自 通信 模块 的 请 求 消 息 ， 并 根据 其 中 的 标识 选择 一 个 Stub 程 序 处 理 。 通 常客 户 端 并 发 请 求 量 比较 大 



































时 ， 会 采用 线程 池 提高 处 理 效率 。 














同步 模式 异步 模式 
客户 端 服务 顺 端 客户 端 服务 


a L 求 [= 发 b k ] 


等 待 应 答 1 处 理 请 求 1 
发 送 应 答 ] 

接收 应 答 1 | 
| 接收 请 求 2 接收 应 答 1 i 


es 处 理 请 : ee 
等 待 应 答 2 处 理 请 求 2 接收 应 答 2 


OB 
接收 应 答 2 














图 4-7 同步 模式 与 异步 模式 对 比 



































接收 请 求 1 
接收 请 求 2 

处 理 请 求 1,2... 
发 送 应 答 1 


发 送 应 答 2 


口 客 户 程序 /服务 过 程 : 请求 的 发 出 者 和 请 求 的 处 理 者 。 如 果 是 单机 环境 ， 客 户 程 序 可 直接 通过 函数 调用 访问 服务 过 程 ， 但 在 分 布 
































式 环境 下 ， 需 要 考虑 网 络 通信 ， 这 不 得 不 增加 通信 模块 和 Stub 程 序 〈 保 证 函数 调用 的 透明 性 ) 
































常 而 言 ， 一 个 RPC 请 求 从 发 送 到 获取 处 理 结果 ， 所 经 历 的 步骤 如 下 《〈 见 图 4-8) : 
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WIRI 客户 程序 以 本 地 方式 调用 系统 产生 的 Stub 程 序 ; 


















































步 又 2 ”该 Stub 程 序 将 函数 调用 信息 按照 网 络 通信 模块 的 要 求 封装 成 消息 包 ， 并 交 给 通信 模块 发 送 到 远程 服务 器 端 ; 











步骤 3 ”远程 服务 器 端 接收 此 消息 后 ， 将 此 消息 发 送 给 相应 的 Stub 程 序 ; 




















步骤 4 Stub 程 序 拆 封 消息 ， 形 成 被 调 过 程 要 求 的 形式 ， 并 调用 对 应 的 函数 ; 











步骤 $ ”被 调用 函数 按照 所 获 参数 执行 ， 并 将 结果 返回 给 Stub 程 序 ; 












































AERO ”Stub 程 序 将 此 结果 封装 成 消息 ， 通 过 网 络 通信 模块 逐 级 地 传送 给 客户 程序 。 














eT eee 。 服务 过 各 


























图 4-8 RPC 通用 架构 
[1] httpyen. wikipedia.org/wiki/Remote Procedure call 


4.3.2 Hadoop RPC 基 本 框架 


1.Hadoop RPC 使 用 
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在 正式 介绍 Hadoop RPC 基 本 框架 之 前 ， 先 介绍 怎么 样 使 用 它 。Hadoop RPC 主 要 对 外 提供 了 两 种 接 

















口 public static VersionedProtocol getProxy/waitForProxy0: 构造 一 个 客户 端 代 理 对 象 ( 该 对 象 实 现 了 某 个 协议 ) ， 用 于 向 服务 器 端 发 送 RPC 
请 求 。 

















口 public static Server getServer0: 为 某 个 协议 《实际 上 是 Java 接 口 ) 实例 构造 一 个 服务 嚣 对象， 用 于 处 理 客户 端 发 送 的 请 求 。 





























通常 而 言 ，Hadoop RPC 使 用 方法 可 分 为 以 下 几 个 步骤 。 




















a 


























步骤 1 定义 RPC 协 议 。RPC 协 议 是 客户 端 和 服务 器 端 之 间 的 通信 接口 ， 它 定义 了 服务 器 端 对 外 提供 的 服务 接口 。 如 以 下 代码 所 示 ， 我 们 
定义 了 一 个 ClientProtocol 通 信 接 口 ， 它 声明 了 两 个 方法 : echo0 和 add0。 需 要 注意 的 是 ，Hadoop 中 所 有 自 定义 RPC 接 口 都 需要 继承 
VersionedProtoco] 接 口 ， 它 描述 了 协议 的 版 本 信息 。 




































































interface ClientProtocol extends org.apache.hadoop.ipc.VersionedProtocol { 
// 版 本 号 。 默 认 情 况 下 ， 不 同 版 本 号 的 RPC Client 和 Server 之 间 不 能 相互 通信 

public static final long versionID=1L; 

String echo (String value) throws IOException; 

int add (int vl, int v2) throws IOException; } 





























步骤 2 实现 RPC 协 议 。Hadoop RPC 协 议 通常 是 一 个 Java 接 口 ， 用 户 需 要 实现 该 接口 。 如 以 下 代码 所 示 ， 对 ClentProtocol 接 口 进行 简单 的 



































public static class ClientProtocolImpl implements ClientProtocol { 
public long getProtocolVersion (String protocol, long clientVersion) { 
return ClientProtocol.versionID; 

} 

public String echo (String value) throws IOException { 

return value; 

} 

public int add (int vl, int v2) throws IOException{ 

return vl+v2; 

} 

} 


















































步骤 3 ”构造 并 启动 RPC Server。 直 接 使 用 静态 方法 getServer0 构 造 一 个 RPC Server， 并 调用 函数 start0 启 动 该 Server: 





server=RPC.getServer (new ClientProtocolImpl(), serverHost, serverPort, 
numHandlers, false, conf) ; 
server.start(); 




















其 中 ，serverHost 和 serverPort 分 别 表示 服务 器 的 host 和 监听 端口 号 ， 而 numHandlers 表 示 服 务 器 端 处 理 请 求 的 线程 数目 。 到 此 为 止 ， 服 务 器 
处 理 监 听 状态 ， 等 待 客户 端 请 求 到 达 。 
























































步骤 4 构造 RPC Clent， 并 发 送 RPC 请 求 。 使 用 静态 方法 getProxy0 构 造 客户 端 代理 对 象 ， 直 接 通过 代理 对 象 调用 远程 端的 方法 ， 有 具体 如 
下 所 示 : 


















































proxy= (ClientProtocol) RPC.getProxy ( 

ClientProtocol.class, ClientProtocol.versionID, addr, conf) ; 
int result=proxy.add (5, 6); 

String echoResult=proxy.echo ("result") ; 
































经 过 以 上 四 步 ， 我 们 便利 用 Hadoop RPC 搭 建 了 一 个 非常 高 效 的 客户 机 /服务 器 网 络 模型 。 接 下 来 ， 我 们 将 深入 Hadoop RPCA HS, HE 
的 设计 原理 及 设计 技巧 。 














Hadoop RPC 主 要 由 三 个 大 类 组 成 ， 分 别 是 RPC、Clent 和 Server， 分 别 对 应 对 外 编程 接口 、 客 户 端 实现 和 服务 器 端 实现 。 




















2.ipc.RPC 类 分 析 

















RPC 类 实际 上 是 对 底层 客户 机 /服务 器 网 络 模型 的 封装 ， 以 便 为 程序 员 提 供 一 套 更 方便 简洁 的 编程 接口 。 























如 图 4-9 所 示 ，RPC 类 自 定义 了 一 个 内 部 类 RPC.Server。 它 继承 Server 抽 象 类 ， 并 利用 Java 反 射 机 制 实现 了 call 接 口 (Server 抽 象 类 中 并 未 给 


























-instance : Object 
-verbose : boclean 


-CLIENTS: RPC.ClientCache 


出 该 接口 的 实现 ) ， 即 根据 客户 端 请 求 中 的 调 月 
户 提供 的 SocketFactory 缓 存 Client 对 象 ， 以 达到 习 



































pan 











jClent 对 象 的 目的 。 








方法 名 称 和 对 应 参数 完成 方法 调用 。RPC 类 包含 一 个 ClientCache 类 型 的 成 员 变 和 
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它 根据 用 
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+getClient(in conf : Configuration, in factory: SocketFactory) : Client 


+getClient(in 


conf) : Client 


+stopClient(in client) 


tcall(in method : Method, in params : Object{][], in addrs : InetSocketAddress, in ticket : UserGroupinformation, in conf : Configuration) 
+getClient(in conf ; Configuration) 
+getProxy(in protocol : Class<?>, in clientVersion: long, in addr, in ticket, in conf, in factory, in rpeTimeout : int) 
+getServer(in instance : Object, in bindAddress : String, in port : int, in numHandlers : int, in verbose : boolean, in conf : Configuration, in secretManager) 


+stopProxy (in proxy : VersionedProtocol) 
+waitForProxy(in protocol : Class<?>, in clientVersion : long, in addr : InetSocketAddress, in conf : Configuration, in rpc Timeout : int, in connlimeout : long) 




















Hadoop RPC 使 用 了 Java 动 态 代 到 








java.lang.reflect.InvocationHandler 接 口 ， 并 按照 
本 地 动态 代理 实例 。 但 对 于 Hadoop RPC， 函 数 调用 由 客户 端 发 出 ， 并 在 服务 器 端 执行 





4-9 Hadoop RPC 的 主要 类 关系 图 
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样 直接 在 invoke 方 法 中 本 地 调 ) 




















相关 函数 ， 它 日 


Si 































































































E (函数 名 、 函 数 参 数列 表 等 ) 




















数 调用 ， 期 间 涉 及 的 类 关系 如 图 4-10 所 示 。 





lient : Client 
-isClosed : boolean 
-remoteld : Client.ConnectionId 


4-10 Hadoop RPC ARS ae 22 AS (CHE SCT 


的 做 法 是 ， 在 jinvoke 方 法 中 ， 将 函数 调用 信和 
Invocation 对 象 ， 并 通过 网 络 发 送 给 服务 器 端 ， 服 务 器 端 收 到 该 调用 信息 后 ， 解 析出 函数 名 和 函数 参数 列表 等 信息 ， 利 | 



































RPC.Invocation 


-methodName : String 
-arameterClasses : Class[ ] 
-parameters : Object[] 
-conf 






































完成 对 远程 方法 的 调用 。 在 4.2.1 小 节 中 ， 我 们 介绍 了 Java 动 态 代理 机 制 : 用 户 只 需 实 现 
自己 的 需求 实现 invoke 方 法 即 可 完成 动态 代理 





类 对 象 上 的 方法 调用 ;我 们 还 在 代码 中 给 出 了 一 个 
并 返回 ， 因 此 不 能 像 4.2.1 节 的 本 地 动态 代理 实例 代码 一 








打包 成 可 序列 化 的 








Java 有 反射 机 制 完成 函 





3.ipc.Client 类 分 析 










































































Client 主 要 完成 的 功能 是 发 送 远程 过 程 调用 信息 并 接收 执行 结果 。 它 涉及 的 类 关系 如 图 4-11 所 示 。Client 类 对 外 提供 了 两 种 接 














， 一 种 用 了 





















































执行 单个 远程 调用 。 另 外 一 种 用 于 执行 批量 远程 调用 。 它 们 的 声明 如 下 所 示 : 











public Writable call (Writable param, ConnectionId remoteId) 

throws InterruptedException, IOException; 

public Writable[]call (Writable[]params, InetSocketAddress[]addresses, 
Class<?>protocol, UserGroupInformation ticket, Configuration conf) 
throws IOException, InterruptedException; 





Clent 内 部 有 两 个 习 

















oh 


要 的 内 部 类 ， 分 别 是 Cal 和 Connection。 


口 Cal 类 : 该 类 封装 了 一 个 RPC 请 求 ， 它 包含 五 个 成 员 变 量 ， 分 别 是 唯一 标识 辽 、 函 数 调用 信息 param、 函 数 执行 返回 值 value、 出 错 或 者 
异常 信息 error 和 执行 完成 标识 符 done。 由 于 Hadoop RPC Server 采 用 了 异步 方式 处 理 客户 端 请 求 ， 这 使 得 远程 过 程 调用 的 发 生 顺 序 与 结果 返回 
顺序 无 直接 关系 ， 而 Client 端 正 是 通过 id 识 别 不 同 的 函数 调用 。 当 客户 端 向 服务 器 端 发 送 请 求 时 
变量 : value, error 和 done， 则 由 服务 器 端 根 据 函 数 执行 情况 填充 。 







































































































































































|， 只 需 填 充 d 和 param 两 个 变量 ， 而 剩 下 的 三 个 

















口 Connection 类 :Client 与 每 个 Server 之 间 维 护 一 个 通信 连接 。 该 连接 相关 的 基本 信息 及 操作 被 封装 到 Connection 类 中 。 J 
要 包括 : 通信 连接 唯一 标识 Cremoteld) ， 与 Server 端 通信 的 Socket (socket) ， 网 络 输入 数据 流 (in) ， 网 络 输 量 
求 的 哈 希 表 (calls) 等 ;操作 则 包括 : 


























出 

















其 中 ， 基 本 信息 主 


























数据 流 Cout) ， 保 存 RPC 请 


DaddCalL 一 将 一 个 Cal 对 象 添加 到 哈 希 表 中 ， 


口 sendParam 一 一 向 服务 器 端 发 送 RPC 请 求 ; 





DreceiveResponse 一 一 从 服务 器 端 接收 已 经 处 理 完 成 的 RPC 请 求 ; 














Drun Connetion 是 一 个 线程 类 ， 它 的 run 方 法 调 








用 了 receiveResponse 方 法 ， 会 一 直 等 待 接收 RPC 返 回 结果 。 











Client 


-<conrections : Hashtable<Connectionld, Connection> 
Counter : int 
sunning : boolean 


-maxIdleTime : int 

=maxRetries : int 

cpNoDelay : boolean 

-pingInterval : int 

+call(in param: Writable, in addr : InetSocketAddress) : Writable 

+call(in params : Writable[], in addresses : InetSocketAddresg{], in ...) : Writable[] 





Client.Call 
-id : int 
-param : Writable 
-value : Writable 


-error : IOException 
-done : boolean 


Client.Connection 


-remoteld : Client.Connectionld 
-socket : Socket 

-in : DatalnputStream 

-out : DataOutputStream 

-calls : Hashtable<Integer, Call> 
+addCall(in call) : boolean 
+sendParam(in sendParam : Client Call) 








-values : Writable -address : InetSocketAddress 
-ticket : UserGroupInformation 
-protocal : Class<?> 





图 4-11 Clent 类 图 





























当 调 用 call 函 数 执行 某 个 远程 方法 时 ，Client 症 需要 进行 如 图 4-12 所 示 的 几 个 步 又 : 








步骤 1 创建 一 个 Connection 对 象 ， 并 将 远程 方法 调用 信息 封装 成 Call 对 象 ， 放 到 Connection 对 象 中 的 哈 希 表 calls 中 ; 


























步骤 2 ”调用 Connetion 类 中 的 sendParam0 方 法 将 当前 Cal 对 象 发 送 给 Server 端 ; 




















步骤 3 Server 端 处 理 完 RPC 请 求 后 ， 将 结果 通过 网 络 返回 给 Clent 峭 ，Clent 端 通过 receiveResponseO 函 数 获取 结果 ; 





步骤 4 ”Client 端 检查 结果 处 理 状 态 〈 成 功 还 是 失败 ) ， 并 将 对 应 的 Cal 对 象 从 哈 希 表 中 删除 。 











© Client 
cal...) Hashtable 


InputStream 





图 4-12 Hadoop RPC Clent 处 理 流程 


4.ipc.Server 类 分 析 














Hadoop 采 用 了 IMaster/Slave 结 构 。 其 中 ，Master 是 整个 系统 的 单 点 ， 如 NameNode 或 JobTracker， 这 是 制约 系统 性 能 和 可 扩展 性 的 最 关键 因 
素 之 一 ， 而 Master 通 过 ipc.Server 接 收 并 处 理 所 有 Slave 发 送 的 请 求 ， 这 就 要 求 ipc.Server 将 高 并 发 和 可 扩展 性 作为 设计 目标 。 为 此 ，ipc.Server 采 
用 了 很 多 具有 提高 并 发 处 理 能 力 的 技术 ， 主 要 包括 线程 池 、 事 件 驱 动 和 Reactor 设 计 模式 等 。 这 些 技术 均 采 用 了 JDKE 自 带 的 库 实 现 。 这 里 重点 
分 析 它 是 如 何 利 用 Reactor 设 计 模式 提高 整体 性 能 世 

























































































imli 















































Reactor 是 并 发 编程 中 的 一 种 基于 事件 驱动 的 设计 模式 。 它 具有 以 下 两 个 特点 : ORIIRE AVOR H E RARER: Orè 
供 了 粗 粒度 的 并 发 控制 ， 使 用 单线 程 实现 ， 避 免 了 复杂 的 同步 处 理 。 一 个 典型 的 Reactor 实 现 原理 图 如 图 4-13 所 示 。 
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图 4-13 Reactor 模式 工作 原理 图 




















个 典型 的 Reactor 模 式 中 主要 包括 以 下 几 个 角色 。 











口 Reactor: IO 事件 的 派发 者 。 








口 Acceptor: 接受 来 自 Client 的 连接 ， 建 立 与 Client 对 应 的 Handler， 并 向 Reactor 洲 





























OHandler: 与 一 个 Client 通 信 的 实体 ， 
decode, compute, encode 和 send 等 的 过 程 。 在 
不 全 ( 读 到 一 


按 一 定 的 过 程 实现 业务 





























E 的 时 候 保 存 上 下 文 ， 并 在 下 一 次 IO 事 件 到 来 的 时 候 〈 男 一 








口 Reader/Sender: Ay Y ask Ab 
待 后 续 处 到 
线程 处 理 。 





速度 ，Reactor 模 式 重 
E 即 可 。 为 此 ，Reactor 模 式 一 般 分 离 Handler 中 的 读 和 写 1 
































ipc.Server 实 际 上 实现 了 一 个 典型 的 Reactor 设 计 模 式 ， 
jpc.Server 的 设计 思路 及 实现 。 接 下 来 ， 我 们 分 析 ipc.Server 
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户 端 





前 面 提 3 功能 是 接收 来 自 客户 端的 RPC 请 求 ， 经 过 调用 相应 的 
此 ，ijipc.Server 被 划分 成 三 个 阶段 : 接收 请 求 ， 处 理 请 求 和 返回 结果 。 如 图 4-14 所 示 ， 





ff 

















pl], ipc.Server 的 主 





(1) 接收 请 求 








Be 
as 





pa yi 


各 个 客户 端的 RPC 请 求 ， 并 将 它们 封装 成 
个 子 阶 段 ， 建立 连接 和 接收 请 求 ， 分 别 由 两 利 


该 阶段 的 主 if 


行 后 续 处 至 


皇 务 是 接收 来 自 
段 内 部 又 分 为 两 












































E。 该 阶 








ae Ie 


的 处 理 。Handler 内 部 得 


个 过 程 ， 分 别 注册 成 各 


EHI (Calek) 放 到 一 个 
线程 完成 : Listener 和 Reader。 


E Wt tt Handler. 


H 4 
E 往 会 











Reactor 模 式 中 ， 业 务 逻 辑 被 分 散 的 IO 事件 所 打破 ， 所 以 Handler 需 要 有 适 


可 读 了 ) 能 继续 





FE 往 构建 一 个 存放 数据 处 理 线程 的 线程 池 ， 这 样 ， 数 据 读 


有 更 进一步 的 层次 划分 ， 用 来 提 








象 诸如 read， 











Ww 




















当 的 机 制 在 所 需 的 信息 还 


上 次 中 断 的 处 理 。 





上 后 ， 立 即 扔 到 线程 池 中 等 
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件 ， 并 由 对 应 的 Reader 和 Sender 
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1 型 的 Reactor 架 构 ， 便 可 很 容易 地 学 习 








函数 获取 结果 后 ， 返 回 








各 阶段 实现 细节 如 下 : 




















给 对 应 的 客 


F= Ùi o 














mi 


























整个 Server 只 有 一 个 Listener 线 程 ， 统 一 听 来 自 客户 端的 连接 请 求 。 





负责 监 





旦 有 新 的 请 求 到 达 ， 

















个 Reader 线 程 进行 处 理 。 而 Reader 线 程 可 同时 存在 多 个 ， 它 们 分 别 负责 接收 


端 连 接 ， 完 全 由 Listener 决 定 。 当 前 Listener 只 是 采用 了 简单 的 轮 询 分 配 机 制 。 


部 分 客 











户 端 











连接 的 RPC 请 求 。 至 于 


t 享 队列 (callQueue〉 中 ， 以 便 进 


它 会 采用 轮 询 的 方式 从 线程 池 中 选择 一 





户 





F 每 个 Reader 线 程 负 责 哪些 客 


Listener 和 Reader 线 程 内 部 各 自 包含 一 个 Selector 对 象 ， 分 别 用 于 监听 SelectionKey.OP_ACCEPT 和 SelectionKey.OP_READ 事 件 。 对 于 Listener 






































































































































线程 ， 主 循环 的 实现 体 是 监听 是 否 有 新 的 连接 请 求 到 达 ， 并 采用 轮 询 策 略 选择 一 个 Reader 线 程 处 理 新 连接 ;对 于 Reader 线 程 ， 主 循环 的 实现 
体 是 监听 〈 它 负责 的 那 部 分 ) 客户 端 连 接 中 是 否 有 新 的 RPC 请 求 到 达 ， 并 将 新 的 RPC 请 求 封 装 成 Call 对 象 ， 放 到 共享 队列 calQueue 中 。 
Clients Server 
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图 414 Hadoop RPC Server 处 理 流 程 








(2) 处 理 请 求 






























































该 阶段 的 主要 任务 是 从 共享 队列 calQueue 中 获取 Cal 对 象 ， 执 行 对 应 的 函数 调用 ， 并 将 结果 返回 给 客户 端 ， 这 全 部 由 Handier 线 程 完成 。 


























Server 端 可 同时 存在 多 个 Handler 线 程 。 它 们 并 行 从 共享 队列 中 读 取 Cal 对 象 ， 经 执行 对 应 的 函数 调用 后 ， 将 尝试 着 直接 将 结果 返回 给 对 应 
的 客户 端 。 但 考虑 到 某 些 函数 调用 返回 的 结果 很 大 或 者 网 络 速度 过 慢 ， 可 能 难以 将 结果 一 次 性 发 送 到 客户 端 ， 此 时 Handler 将 尝试 着 将 后 续 发 
送 任务 交 给 Responder 线 程 。 



























































(3) 返回 结果 


























前 面 提 到 ， 每 个 Handler 线 程 执行 完 函 数 调用 后 ， 会 尝试 着 将 执行 结果 返回 给 客户 端 ， 但 对 于 特殊 情况 ， 比 如 函数 调用 返回 的 结果 过 大 或 
者 网 络 异 常情 况 〈 网 速 过 慢 ) ， 会 将 发 送 任务 交 给 Responder 线 程 。 
































Server 端 仅 存在 一 个 Responder 线 程 。 它 的 内 部 包含 一 个 Selector 对 象 ， 用 于 监听 SelectionKey.OP_WRITE 事 件 。 当 Handler 没 能 够 将 结果 一 次 
































性 发 送 到 客户 端 时 ， 会 向 该 Selector 对 象 注册 SelectionKey.OP_WRITE 事 件 ， 进 而 由 Responder 线 程 采 用 异步 方式 继续 发 送 未 发 送 完 成 的 结果 。 





























5.Hadoop RPC 参 数 调 优 

































































Hadoop RPC 对 外 提供 了 一 些 可 配置 参数 ， 以 便于 用 户 根据 业务 需求 和 硬件 环境 对 其 进行 调 优 ， 主 要 的 配置 参数 如 下 。 


















































口 Reader 线 程 数目 : 由 参数 jpc.serverread.threadpoolsize 配 置 ， 默 认 是 1。 也 就 是 说 ， 默 认 情况 下 ， 一 个 RPC Server 只 包含 一 个 Reader 线 程 。 











口 每 个 Handler 线 程 对 应 的 最 大 Cal 数 目 : 由 参数 jpc.serverhandler.queue.size 指 定 ， 默 认 是 100。 也 就 是 说 ， 默 认 情 况 下 ， 每 个 Handler 线 程 对 
应 的 Call 队 列 长 度 为 100。 比 如 ， 如 果 Handlker 数 目 为 10， 则 整个 Call 愉 列 《〈 共 享 队列 calQueue) 最 大 长 度 为 : 100x10=1 000. 





























口 Handlet 线 程 数目 : 在 Hadoop 中 ，JobTracker 和 NameNode 分 别 是 MapReduce 和 HDFS 两 个 子 系统 中 的 RPC Server， 其 对 应 的 Handler 数 目 分 
别 由 参数 mapred.job.tracker.handler.count 和 dk.namenode.service.handler.count 指 定 ， 默 认 值 均 为 10。 当 外 
系统 性 能 。 


























群 规模 较 大 时 ， 这 两 个 参数 值 会 大 大 影响 


aur 




















口 客户 端 最 大 重 试 次 数 : 在 分 布 式 环境 下 ， 因 网 络 故 障 或 者 其 他 原因 迫使 客户 端 重 试 连接 是 很 常见 的 ， 但 尝试 次 数 过 多 可 能 不 利于 对 实 



























































时 性 要 求 较 高 的 应 用 。 客 户 端 最 大 重 试 次 数 由 参数 jpc.client.connect.max.retries 指 定 ， 默 认 值 为 10， 也 就 是 会 连续 尝试 10 次 (每 两 次 之 间 相 隔 1 
秒 钟 )。 











4.3.3 ”集成 其 他 开源 RPC 框 架 








当前 存在 非常 多 的 开源 RPC 框 架 ， 比 较 有 名 的 有 Thrif |"! , Protocol Buffers '7! 和 Avro Pl. Hadoop RPC 一 样 ， 它 们 均 由 两 部 分 组 成 : 对 
象 序列 化 和 远程 过 程 调用 。 相 比 于 Hadoop RPC， 它 们 有 以 下 几 个 特点 。 
















































































口 跨 语 言 特 性 : 前 面 提 到 ，RPC 框 架 实际 上 是 客户 机 /服务 器 模型 的 一 个 应 用 实例 。 对 于 Hadoop RPC 而 言 ， 由 于 Hadoop 采 用 Java 语 言 编 
写 ， 因 而 其 RPC 客 户 端 和 服务 器 端 仅 支持 Java 语 言 ， 但 对 于 更 通用 的 RPC 框 架 ， 如 Thrift 或 者 Protocol Buffers 等 ， 其 客户 端 和 服务 器 端 可 采用 
任何 语言 编写 ， 如 Java, C++，Python 等 ， 这 给 用 户 编 程 带 来 极 大 的 方便 。 


















































































































































口 引 入 IDL: 开源 RPC 框 架 均 提供 了 一 套 接口 描述 语言 (Interface Description Language, IDL) 。 它 提供 一 套 通用 的 数据 类 型 ， 并 以 这 些 
数据 类 型 来 定义 更 为 复杂 的 数据 类 型 和 对 外 服务 接口 。 一 旦 用 户 按照 IDL 定 义 的 语法 编写 完 接 口 文件 后 ， 即 可 根据 实际 应 用 需要 生成 特定 
的 编程 语言 (如 Java, C++H，Python 等 ) 的 客户 端 和 服务 器 端 代 码 。 



























































































































































口 协议 兼容 性 : 开源 RPC 框 架 在 设计 上 均 考 虑 到 了 协议 兼容 性 问题 ， 即 当 协 议 格式 发 生 改 变 时 ， 比 如 某 个 类 需要 添加 或 者 删除 一 个 成 
员 变 量 字段， 后， 旧版 本 代码 仍然 能 识别 新 格式 的 数据 ， 也 就 是 说 ， 上 共有 向 后 兼容 性 。 




























































































随 着 Hadoop 版 本 的 不 断 演化 ， 研 发 人 员 发 现 Hadoop RPC 在 跨 语言 支持 和 协议 兼容 性 两 个 方面 存在 不 足 ， 具 体 表 现 为 : 

































































D 从 长 远 发 展 看 ，Hadoop RPC 应 允许 某 些 协 议 的 客户 端 或 者 服务 器 端 采用 其 他 语言 实现 ， 比 如 用 户 希 望 直接 使 用 C/C++ 语言 读 写 
HDFS 中 的 文件 ， 这 就 需要 有 C/C++ 语言 的 HDFS 客 户 端 。 






























































2) 当前 Hadoop 版 本 较 多 ， 而 不 同 版 本 之 间 不 能 通信 。 比 如 ，0.20.2 版 本 的 JobTracker 不 能 与 0.21.0 版 本 中 的 TaskTracker 通 信 ， 如 果 用 户 
企图 这 样 做 ， 会 抛 出 VersionMismatch 异 常 。 





























为 了 解决 以 上 几 个 问题 ， 从 0.21.0 版 本 开始 ，Hadoop 尝 试 着 将 RPC 中 的 序列 化 部 分 剥离 开 ， 以 便 将 现 有 的 开源 RPC 框 架 集成 进来 。 改 
进 之 后 ，Hadoop RPC 的 类 关系 如 图 4-15 所 示 。RPC 类 变 成 了 一 个 工厂 ， 它 将 具体 的 RPC 实 现 授 权 给 RpcEngine 实 现 类 ， 而 现 
要 实现 RpcEngine 接 口 ， 便 可 以 集成 到 Hadoop RPC 中 。 在 该 图 中 ，WritableRpcEngine 是 采用 Hadoop 自 带 的 序列 化 框架 实现 的 RPC， 而 
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AvroRpcEngine !“! #11 ProtobufRpcEngine 中 分 别 是 开源 RPC 框 架 Ayro 和 Protocol Buffers 对 应 的 RpcEngine 接 口 实现 。 用 户 可 通过 配置 参数 rpc.engine. 
{protocol} 以 指定 协议 {protocol} 采 用 的 RPC 框 架 。 需 要 注意 的 是 ， 当 前 实现 中 ，Hadoop RPC 只 采用 这 些 开源 框架 的 序列 化 机 制 ， 底 层 的 函 
数 调 用 机 制 仍 采用 Hadoop 自 带 的 。 










































































=PROTOCOL_ENGINES: Map<Class RpcEngine> 

-PROXY_ENGINES: Map<Class, RpcEngine > 

+call(in method : Method, in params : Object{][], in addrs : InetSocketAddress, in ticket : UserGroupInformation, in conf : Configuration) : Object[][] 
+getProxy(in protocol : Class<?>, in clientVersion : long, in addr : InetSocketAddress, in ...) :Object 

+getServer(in protocal : Class<?>, in instance : Object, in bindAddress : String, in port : int, in numHandlers : int, in ...) :RPC.Server 

+stopProxy(in proxy : Object) 

+waitForProxy(in protocol : Class<?>, in clientVersion : long, in addr : InetSocketAddress, in conf : Configuration, in timeout : long) : Object 
+getProtocolEngine() : RpcEngine 

+getProxyEngine() : RpcEngine 

+setProtocolEngine(in conf : Configuration, in protocol : Class, in engine : Class) 


+getProxyin protocal : Class, in clientVersion : long, in addr : InetSocketAdadress, in ...) : Object 
+stopProxy() : Object 

teall(in method : Method, in params : Object{}]{[], in...) :Object{] 

tgetServer(in protocal : Class, in instance : Object, in bindAddress : String, in port : int, in...) : RPCServer 


ProtobufRpcEngine 


4-15 Hadoop RPC 集 成 多 种 开源 RPC 框 架 









WritableRpcEngine 

















在 下 一 代 的 Hadoop (参见 第 12 章 ) 中 ， 已 将 Protocol Buffers 作 为 默认 的 序列 化 机 制 四 〈 而 不 是 Hadoop 自 带 的 Writable) ， 这 带 来 的 好 处 
主要 表现 在 以 下 几 个 方面 。 























(1) 继承 了 Protocol Buffers 的 优势 























Protocol Buffers 已 在 实践 中 证 明了 其 高 效 性 ， 可 扩展 性 ， 紧 凑 性 和 跨 语言 特性 。 首 先 ， 它 允许 在 保持 向 后 兼容 性 的 前 提 下 修改 协议 ， 比 
如 为 某 个 定义 好 的 数据 格式 添加 一 个 新 的 字段 ， 其 次 ， 它 支持 多 种 语言 ， 进 而 方便 用 户 为 某 些 服务 〈 比 如 HDFS 的 NameNode) 编写 非 Java 
客户 端 ， 此 外 ， 实 验 表 明 Protocol Buffers 比 Hadoop 自 带 的 Writablke 在 性 能 方面 有 很 大 提升 。 
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D 支持 升级 回 深 

















Hadoop 2. 0.0 及 其 以 上 版 本 中 已 经 将 NameNode HA 方案 合并 进来 。 在 该 方案 中 ，NameNode 有 两 种 角色 : Active 和 Standby。 其 中 ，Active 
NameNode 是 当前 对 外 提供 服务 ， 而 Standby NameNode 则 能 够 在 Active NameNode 出 现 故 障 时 接替 它 。 采 用 Protocol Buffers 序 列 化 机 制 后 ， 管 
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fd 



























































理 员 能 够 在 不 停止 NameNode 对 外 服务 的 前 提 下 ， 通 过 主 备 NameNode 之 间 的 切换 ， 依 次 对 主 备 NameNode 进 行 在 线 升 级 不 用 考虑 版 本 和 


协议 兼容 性 等 问题 ) 。 





























[1] http//thrift. apache.org/ 

[2] http//code. google.con/p/protobuf? 

[3] http//avro. apache.org/ 

[4] AvroRpcEngine\ Hadoop 0.21.0 版 本 开始 出 现 。 
[5] ProtobufRpcEngine 从 Hadoop 2.0-apha 版 本 开始 出 现 。 
[6] httpsVissues. apache. org/jira/browse/HADOOP-7347 











4.4 MapReduce 通 信 协 议 分 析 


本 书 重点 介绍 MapReduce， 因 此 对 Hadoop RPC 上 层 系统 的 分 析 也 只 限于 MapReduce 分 布 式 计算 框架 。 在 Hadoop MapReduce 
中 ， 不 同 组 件 之 间 的 通信 协议 均 是 基于 RPC 的 。 它 们 就 像 系统 的 “骨架 ”， 支 撑 起 整个 MapReduce 系 统 。 本 节 我 们 将 详细 介绍 
Hadoop MapReduce 中 所 有 基于 RPC 的 通信 协议 。 
































4.4.1 MapReduce 通 信 协 议 概 述 





















































在 Hadoop 1.0.0 版 本 中 ，MapReduce 框 架 中 共有 6 个 主要 的 通信 协议 ， 有 具体 如 图 4-16 所 示 。 其 中 ， 直 接 面向 Client《〈 用 户 ) 的 通 
信 协 议 共 有 4 个 。 





















































OJobSubmissionProtocol!!!; Client (一 般 为 普通 用 户 ) 与 JobTracker 之 间 的 通信 协议 。 用 户 通 过 该 协议 提交 作业 ， 查 看 作业 运 


行情 况 等 。 



































Q RefreshUserMappingsProtoco]: Client 一 般 为 管理 员 )〉 通过 该 协议 更 新 用 户 -用 户 组 映射 关系 。 








Q RefreshAuthorizationPolicyProtocol: Clent 一 般 为 管理 员 ) 通过 该 协议 更 新 MapReduce 服 务 级 别 访问 控制 列表 。 











口 AdminOperationsProtocol，Clent〈 一 般 为 管理 员 ) 通过 该 协议 更 新 队列 〈 存 在 于 JobTracker 或 者 Scheduler 中 ) 访问 控制 列表 
和 节点 列表 。 






































在 Hadoop 线 上 环境 中 ， 考 虑 到 安全 因素 ， 通 常 将 JobSubmissionProtocol 使 用 权限 授予 普通 用 户 ， 而 其 他 三 个 通信 协议 的 权限 授 
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图 4-16 Hadoop MapReduce 通 信 协 议 概 览 
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另外 ， 两 个 通信 协议 位 于 MapReduce 框 架 内 部 ， 如 

















口 InterTrackerProtocol: TaskTracker 与 JobTracker 之 间 的 通信 协议 。TaskTracker 通 过 相关 接口 汇报 本 节点 的 资源 使 用 情况 和 任 
务 运行 状态 等 信息 ， 并 执行 JobTracker 发 送 的 命令 。 















































QOTaskUnbilicalProtocol: Task 与 TaskTracker 之 间 的 通信 协议 。 每 个 Task 实 际 上 是 其 同 节点 TaskTracker 的 子 进程 ， 它 们 通过 该 
协议 汇报 Task 运 行 状态 、 运 行进 度 等 信息 。 


















































在 Hadoop 中 ， 所 有 使 用 Hadoop RPC 的 协议 基 类 均 为 VersionedProtocol。 该 类 主要 用 于 描述 协议 版 本 号 ， 以 防止 不 同 版 本 号 的 
客户 端 与 服务 器 端 之 间 通 信 。 在 Hadoop MapReduce 中 ， 这 六 个 通信 协议 与 JobTracker, TaskTracker 的 类 关系 如 图 4-17 所 示 。 
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图 4-17 Hadoop MapReduce 通 信 协 议 类 关系 
[1] Hadoop 0. 21.0 以 及 之 后 的 版 本 已 将 该 协议 名 称 改 成 ClientProtocol。 









































JobTracker 









VersionedProtocol 






TaskTracker 











4.4.2 ”JobSubmissionProtocol 通 信 协 议 





























] 户 可 通过 该 协议 提交 作业 和 查看 作业 运行 状态 。 该 协议 中 的 接 























JobSubmissionProtoco] 是 Client 与 JobTracker 之 间 的 通信 协议 。 


口 可 分 为 三 类 : 





C1) 作业 提交 








Client 可 通过 以 下 RPC 函 数 提交 作业 : 











public JobStatus submitJob (JobID jobName, String jobSubmitDir, Credentials ts) throws IOException 


其 中 ，jobName 为 该 作业 的 ID, Clent 可 通过 getNewJobId0 函 数 为 作业 获取 一 个 唯一 的 ID; jobSubmitDir 为 作业 文件 《如 jar 
包 ，xm 文 件 等 ) 所 在 的 一 般 为 HDFS 上 的 一 个 目录 ; ts 是 该 作业 分 配 到 的 密 钥 或 者 安全 令 牌 。 
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(2) 作业 控 币 
有 三 个 操作 : 修改 其 作业 优先 级 (setJobPriority 函 数 ) 、 杀 死 一 个 作业 
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当 用 户 提交 作业 之 后 ， 可 进一步 控制 该 作业 ， 


(kiJob 函 数 ) 、 杀 死 一 个 任务 CkilTask O 。 

















(3) 查看 系统 状态 和 作业 运行 状态 


























F 面 是 其 中 几 个 函数 的 声明 : 
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// 获 取 集 群 当前 状态 ， 如 slot 总 数 ， 所 有 正在 运行 的 Task 数 
public ClusterStatus getClusterStatus (boolean ‘detailed) throws IOException; 
// 获 取 某 个 作业 的 运行 状态 

public JobStatus getJobStatus (JobID jobid) throws IOException; 
了 7 获取 所 有 作 的 运行 状态 

public JobStatus[]getAllJdobs()throws IOException; 


























4.4.3 ”InterTrackerProtocol 通 信 协 议 





TaskTracker 通 过 该 协议 向 JobTracker 汇 报 所 在 节点 的 资源 使 用 





InterTrackerProtocol 是 TaskTracker 与 JobTracker 之 间 的 通信 协议 。 
情况 和 任务 运行 状况 ， 并 接收 和 执行 JobTracker 返 回 的 命令 。 
































该 协议 中 最 重要 的 一 个 方法 是 heartbeat。 它 周期 性 地 被 调用 ， 进 而 形成 了 TaskTracker 与 JobTracker 之 间 的 心跳 。 其 定义 如 下 : 








HeartbeatResponse heartbeat (TaskTrackerStatus status, 
boolean restarted, 

boolean initialContact, 

boolean acceptNewTasks, 

short responseld) 

throws IOException; 


























该 函数 的 一 个 重要 输入 参数 为 TaskTrackerStatus 类 型 的 status。 它 封装 了 所 在 节点 的 资源 使 用 情况 (物理 内 存 和 虚拟 内 存 总 量 
和 使 用 量 ，CPU 个 数 以 及 利用 率 等 ) 和 任务 运行 情况 〈 每 个 任务 运行 进度 ， 状 态 以 及 所 处 的 阶段 等 ) 。 函 数 返 回 值 类 型 为 
HeartbeatResponse。 它 包含 了 一 个 TaskTrackerAction 类 型 的 数组 。 该 数组 包含 了 JobTracker 向 TaskTracker 传 达 的 各 种 命令 〈 我 们 将 
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在 7.4 节 详细 介绍 这 几 个 命令 ) ， 主 要 分 为 以 下 几 种 类 型 。 











OCommitTaskAction: Task 运 行 完 成 ， 提 交 其 产生 的 结果 。 





口 ReinitTrackerAction: 重新 对 自己 《〈TaskTracker) 初始 化 。 



































OKilobAction: 杀 死 某 个 作业 ， 并 清理 其 使 用 的 资源 。 








OKillTaskAction: 杀 死 某 个 任务 。 








口 LaunchTaskAction: 启动 一 个 新 任务 。 












































该 协议 中 其 他 几 个 均 是 getter 方 法 ， 用 于 从 JobTracker 中 获取 信息 : 








// 从 JobTracker 中 获取 某 个 作业 已 经 完成 的 Task 列 表 ， 这 主要 是 为 Reduce Task 获 取 已 完成 的 
Map Task 列表， 以 便 开 始 远程 拷贝 (shuffle) 数据 
TaskCompletionEvent []getTaskCompletionEvents (JobID jobid, int 
, int maxEvents) throws IOException; 
// 获 取 JobTracker 指 定 的 系统 目录 ， 以 便 TaskTrackezr 将 作业 相关 的 文件 存放 到 该 目录 中 
public String getSystemDir(); 

// 获 取 JobTracker 编 译 版 本 号 ，TaskTracker 与 JobTracker 编 译 版 本 号 一 致 才 可 启动 
public String getBuildVersion()throws IOException; 














fromEventId 






































4.4.4 ”TaskUmbilicalProtocol 通 信 协 议 

















TaskUnbilicalProtocol 是 Task 与 TaskTracker 之 间 的 通信 协议 。 每 个 Task 通 过 该 协议 向 对 应 的 TaskTracker 汇 报 自己 的 运行 状况 或 





者 出 错 信息 。 














按照 调用 频率 ， 可 将 该 协议 中 的 方法 分 为 两 类 : 一 类 是 周期 性 被 调用 的 方法 ， 另 一 类 是 按 需 调用 的 方法 。 其 中 ， 第 一 类 方法 























主要 有 以 下 两 个 : 

































































//Task 向 TaskTracker 汇 报 自己 的 当前 状态 ， 状 态 信 息 被 封装 到 TaskStatus 中 











boolean statusUpdate (TaskAt 








temptID taskId, TaskStatus taskStatus, 


JvmContext jvmContext) throws IOException, InterruptedException; 





//Task 周 期 性 探测 TaskTracker 是 否 活着 
boolean ping (TaskAttemptID 











taskid, JvmContext jJvmContext) throws IOException; 




















> 








这 两 个 方法 并 不 是 





statusUpdate 函 数 向 TaskTJracker 江 报 最 新 进度 。 然 而 ， 如 果 Task 在 3s 内 没有 处 理 任何 数据 《比如 当前 记录 处 理 速度 太 慢 ) ， 则 不 再 





















































目 互 独立 的 ， 它 们 之 间 相 互 合作 ， 共 同 完成 Task 状 态 汇 报 的 任务 。 一 般 情 况 下 ，Task 每 隔 3s 会 调用 一 次 



















































































汇报 进度 ， 而 是 直接 调用 ping 方 法 探测 TaskTracker， 以 确保 当前 数据 处 理 过 程 中 它 一 直 是 活 的 。 























第 二 类 方法 在 Task 的 不 同 运行 阶段 被 调用 ， 其 调用 时 机 依次 为 : 


C1) Task 初 始 化 




















TaskTracker 从 JobTracker 那 里 接收 到 一 个 启动 新 Task 的 命令 CLaunchTaskAction) 后 ， 首 先 创建 一 个 子 进程 (Child) ， 并 由 该 
子 进 程 调用 getTask 方 法 领取 对 应 的 Task。 





























(2) Task 运 行 中 






































汇报 错误 及 异常 :Task 运 行 过 程 中 可 能 会 出 现 各 种 异常 或 者 错误 ， 而 reportDiagnosticInfo/ 人 GError/fatalError 方 法 则 分 别 用 以 汇 





报 出 现 的 Exception/FSError/Throwable 异 常 和 错误 。 对 于 Reduce Task 而 言 ， 还 提供 了 shuffleError 方 法 汇报 Shuffle 阶 段 出 现 的 错误 。 























口 汇报 记录 范围 Hadoop 可 通过 跳 过 坏 记 录 提 高 程序 的 容错 性 (具体 参考 6.5.4 节 ) 。 为 了 便于 定位 坏 记 录 的 位 置 ，Task 需 要 
通过 reportNextRecordRange 方 法 不 断 向 TaskTracker 汇 报 将 要 处 理 的 记录 范围 。 









































口 获取 Map Task 完 成 列表 : 在 MapReduce 框 架 中 ，Reduce Task 与 Map Task 之 间 存 在 数据 依赖 关系 。 该 协议 专门 为 Reduce Task 









































提供 了 getMapCompletionEvent 方 法 ， 以 方便 其 从 TaskTracker 获 取 已 经 完成 的 Map Task 列 表 ， 进 而 能 够 获取 Map Task 产 生 的 临时 数 





























(3) Task 运 行 完成 








据 存放 位 置 ， 并 远程 读 取 (对 应 Reduce Task 的 Shuffle 阶 段 ， 这 些 数 据 。 















































当 Task 处 理 完 最 后 一 条 记录 后 ， 会 依次 调用 commitPending, canCommit 和 done 三 个 方法 完成 最 后 的 收尾 工作 。 


4.4.5 其 他 通信 协议 


新 Hadoop MapReduce 的 相关 配置 文件 。 


其 他 三 个 通信 协议 ， 即 ReftreshUserMappingsProtocol, RefreshAuthorizationPolicyProto-col 和 AdminOperationsProtocol， 均 
这 些 配置 文件 涉及 对 Hadoop 某 些 模块 的 访问 权限 ， 因 而 往往 只 将 其 使 

















别 较 高 的 

















和 户 〈 比 如 Hadoop 管 理 员 ) 。 











(1) ReffeshUserMappingsProtocol 协 议 


该 协议 有 两 个 作用 : 






































更 新 用 户 - 














j 户 组 映射 关系 和 更 新 超级 用 户 代理 列表 ， 


























于 动态 更 
权限 授予 一 些 级 


























分 别 对 应 以 下 两 个 方法 : 











public void refreshUserToGroupsMappings ()throws IOException; 
public void refreshSuperUserGroupsConfiguration()throws IOException; 








为 了 方便 
默认 情况 下 ，Hadoop 使 
某 些 用 户 的 映射 关系 ， 则 可 使 









































j 户 执行 以 上 两 个 操作 ，Hadoop 对 其 












































进行 了 封闭， 用 户 直接 使 用 相应 的 Shel 命 令 即 可 完成 更 新 操作 。 











]UNIX/Linux 系 统 中 自 带 的 用 户 -用 户 组 映射 关系 ， 且 对 其 进行 了 缓存 。 
| 以 下 Shel 命 令 更 新 到 Hadoop MapReduce 绥 存 中 : 














如 果 管 





BAL 








UNIX 中 修改 了 














bin/hadoop mradmin-refreshUserToGroupsMappings 




















































































































































































































































































































































































































Hadoop 提 供 了 一 种 代理 机 制 ， 允 许 某 些 用 户 伪 装 成 其 他 用 户 执 行 某 些 操 作 。 用 户 可 在 core-site.xml 配 置 文 件 中 添加 以 下 配置 选 
项 : 
<property> 
<name>hadoop.proxyuser.oozie.groups</name> 
<value>groupl, group2</value> 
< description> 超 级 用 户 oozie 可 伪装 成 分 组 group1 和 group2 中 的 任何 用 户 < /description> 
</property> 
<property> 
<name>hadoop.proxyuser.oozie.hosts</name> 
<value>hostl, host2</value> 
<description> 超 级 用 户 oozie 只 能 在 host1 和 host2 两 个 节点 上 进行 伪装 < /description></property> 
经 过 以 上 配置 后 ， 只 要 用 户 oozie 拥 有 Hadoop Kerberos key (具体 参考 第 11 章 ) ， 则 hostL 和 host2 两 个 节点 上 group1 和 group2 两 
个 组 中 的 所 有 用 户 可 统一 以 用 户 ooze 的 身份 提交 作业 。 
管理 员 可 动态 修改 这 种 超级 用 户 代 理 列 表 ， 并 通过 以 下 命令 完成 更 新 操作 : 
bin/hadoop mradmin-refreshSuperUserGroupsConfiguration 
(2) RefreshAuthorizationPolicyProtocoltp i 
该 协议 用 于 更 新 MapReduce 服 务 级 别 访问 控制 列表 ， 其 中 “服务 级 别 访问 控制 列表 ”实际 上 是 每 个 通信 协议 的 访问 控制 列表 。 
每 种 通信 协议 均 对 应 一 定 的 访问 权限 ， 比 如 ， 拥 有 JobSubmissionProtocol 协 议 访问 权限 的 用 户 可 以 提交 作业 ， 查 看 作业 运行 情况 
等 。 每 个 协议 的 访问 控制 列表 可 在 配置 文件 hadoop-policy.xml 中 配置 ， 比 如 : 
<property> 
<name>security.job.submission.protocol.acl</name> 
<value>userl, user2 groupl, group2</value> 
</property> 
经 过 以 上 配置 后 ， 用 户 userl、user2， 用 户 组 group1、group2 拥 有 了 JobSubmissionProtocol 协 议 的 访问 权限 ， 他 们 可 以 向 Hadoop 
提交 作业 、 查 看 作业 运行 情况 等 。 
管理 员 可 以 直接 通过 以 下 命令 动态 更 新 配置 文件 hadoop-policy.xml: 





bin/hadoop mradmin-refreshServiceAcl 


























该 命令 最 终 会 调用 RefreshAuthorizationPolicyProtocol 协 议 中 的 refreshServiceAc 方 法 完成 更 新 操作 。 











(3) AdminOperationsProtocol 协 议 




















该 协议 提供 











于 更 新 队列 访问 控制 列表 CrefreshQueues) 和 更 新 节点 列表 (reftreshNodes〉 的 两 个 方法 。 




















口 更 新 队列 访 














问 控制 列表 : Hadoop 以 队列 为 单位 管理 用 户 ， 管 理 员 可 配置 队列 与 操作 系统 用 户 和 用 户 组 之 间 的 映射 关系 ， 





















































每 个 队列 对 应 的 











户 或 者 用 户 组 称 为 该 队列 的 访问 控制 列表 。 在 Hadoop 中 ， 队 列 访问 控制 列表 信息 可 能 存在 于 配置 文件 mapred- 





















































queue-acls.xml 和 调度 器 配置 文件 中 。 在 配置 文件 mapred-queue-acls.xml 中 ， 管 理 员 可 为 每 个 队列 配置 两 种 权限 : 提交 作业 权限 和 管 























理 作业 权限 。 对 于 

















Th 




















某 个 用 户 而 言 ， 拥 有 某 个 队列 的 作业 提交 权限 意味 着 该 用 户 可 向 该 队列 提交 作业 并 使 用 该 队列 中 的 计算 资源 ， 



































而 拥有 队列 的 作业 





管理 权限 意味 着 该 用 户 可 以 改变 任何 作业 的 优先 级 、 杀 和 死 任何 作业 等 ， 比 如 ; 











<property> 


<name>mapred. queue .myqueue.acl-submit-job</name> 
<value>userl, user2 groupl</value 


<description 
</property> 
<property> 
































> 
> 用 户 user1、user2 和 用 户 组 group1 可 向 队列 myqueue 中 提交 作业 和/description> 

















<name>œ>mapred. queue .myqueue.acl-administer-job</name> 
<value>userl</value> 


<description 
</property> 

















> 用 户 user1 可 管理 队列 myqueue<</description> 





























管理 员 可 通过 





以 下 命令 动态 加 载 相关 配置 文件 : 











bin/hadoop mradmin-refreshQueues 
































口 更 新 节点 列表 : Hadoop 人 允许 管理 员 为 节点 建立 白 名单 〈 完 全 可 以 信赖 的 节点 列表 ) 和 黑 名单 〈 不 允许 加 入 Hadoop 集 群 的 








节点 列表 ) 。 其 中 ， 白 名 单 可 通过 配置 选 


项 指定 (在 mapred-site.xml 中 ) 。 管 理 员 可 通过 以 下 命令 动态 更 新 这 两 个 名 单 : 





ji 
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页 mapred.hosts〈 在 mapred-site.xml 中 ) 指定 ， 而 黑 名 单 可 通过 mapred.hosts.exclude 配 置 选 
















































































bin/hadoop mradmin-refreshNodes 





a5 aa 

















Hadoop RPC 是 Hadoop 多 个 子 系统 公用 的 网 络 通信 模块 。 其 性 能 和 可 扩展 性 直接 影响 其 上 层 系统 的 性 能 和 可 扩展 性 ， 因 此 扮 
演 着 极其 重要 的 角色 。 






































Tay} 



















































































Hadoop RPC 分 为 两 层 ， 上 层 是 直接 供 外 面 使 用 的 公共 RPC 接 口 ， 下 层 是 一 个 客户 机 /服务 器 模型 ， 该 模型 在 实现 过 程 中 用 到 
了 Java 自 带 的 多 个 工具 包 ， 包 括 java.angrefect《〈 反 射 机 制 和 动态 代理 相关 类 ) 、java.net〔 网 络 编程 库 ) 和 java.nio (NIO) 等 。 














































































































Hadoop RPC 主 要 由 三 个 大 类 组 成 ， 分 别 是 RPC、Client 和 Server， 分 别 对 应 对 外 编程 接口 、 客 户 端 实现 和 服务 器 端 实现 。 其 
中 ，Server 具 有 高 性 能 和 良好 的 可 扩展 性 等 特点 ， 在 具体 实现 时 采用 了 线程 池 、 事 件 驱 动 和 Reactor 设 计 模 式 等 机 制 |。 
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Hadoop MapReduce 基 于 RPC 框 架 实现 了 6 个 通信 协议 ， 分 别 是 JobSubmissionsProtocol RefreshUserMappingsProtocol, 
RefreshAuthorizationPolicyProtocol, AdminOperationsProtocol, InterTrackerProtocol 和 TaskUmbilicalProtocol。 这 些 协议 像 是 系统 的 骨架” 
支撑 起 整个 MapReduce 系 统 。 














第 5 革 ”作业 提交 与 初始 化 过 程 分 析 























[EHI 


架 ， 这 是 MapReduce 运 行 时 环境 的 基础 。 从 本 章 开始 ， 我 们 将 以 “作业 的 生命 周期 "为 轴线 介绍 





前 面 一 章 介 绍 了 Hadoop RPCH 
MapReduce 内 部 实现 原理 。 









































在 本 章 中 ， 我 们 将 深入 分 析 一 个 MapReduce 作 业 的 提交 与 初始 化 过 程 ， 即 从 用 户 输入 提交 作业 命令 到 作业 初始 化 的 整个 过 
程 。 该 过 程 涉及 JobClient、jJobTracker 和 TaskScheduler 三 个 组 件 ， 它 们 的 功能 分 别 是 准备 运行 环境 、 接 收 作业 以 及 初始 化 作业 。 我 
们 将 在 本 章 中 深入 分 析 这 三 个 组 件 。 





























5.1 ”作业 提交 与 初始 化 概述 











总 体 而 言 ， 作 业 提 交 过 程 比较 简单 ， 它 主要 为 后 续 作业 执行 准备 环境 ， 主 要 涉及 创建 目录 、 上 传 文件 等 操作 ， 而 一 旦 用 户 提 
交 作业 后 ，JobTracker 滑 便 会 对 作业 进行 初始 化 。 作 业 初 始 化 的 主要 工作 是 根据 输入 数据 量 和 作业 配置 参数 将 作业 分 解 成 若干 个 
Map Task 以 及 Reduce Task， 并 添加 到 相关 数据 结构 中 ， 以 等 待 后 续 被 调度 执行 。 总 之 ， 可 将 作业 提交 与 初始 化 过 程 分 为 四 个 步 
又 ， 如 图 5-1 所 示 。 
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图 5-1 MapReduce 作 业 提 交 与 初始 化 过 程 


achives 















































步骤 1 用 户 使 用 Hadoop 提 供 的 Shel 命 令 提交 作业 。 
































FE 上传 到 JobTracker 文 件 系 统 (通常 为 HDFS， 本 书 








H> 
Dkr 
yd 
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步骤 2 JobClient 按 照 作业 配置 信息 (JonConf) 将 作业 运行 需要 的 
统一 采用 HDFS) 的 某 个 目录 下 。 


























步骤 3 ”JobClient 调 用 RPC 接 口 向 JobTracker 提 交 作 业 。 


步骤 4 JobTracker 接 收 到 作业 后 ， 将 其 告知 TaskScheduler， 由 TaskScheduler 对 作业 进行 初始 化 。 


简称 “作业 文件 ”上 传 到 HDFS 






































在 步骤 2 中 ， 之 所 以 将 作业 相关 文件 〈 包 括 应 用 程序 jar 包 、xml 文 件 及 其 依赖 的 文件 等 ， 后 画 


要 是 出 于 以 下 两 点 考虑 : 












































E; 了 


vty 





F。 也 就 是 说 ，HDFS 上 所 有 文件 























F 系 统 ，Hadoop 集 群 中 任何 一 个 节点 可 以 直接 从 该 系统 中 下 载 文 伯 


Ji 











OHDFSÆ— 784) 49 R14 
都 是 节点 间 共 享 的 〈 不 考虑 文件 权限 ) 。 


















































个 Task 只 需 知 道 存 放 路 径 便 可 以 下 载 到 自己 的 工作 








F 是 运行 Task 所 必需 的 。 它 们 一 旦 被 上 传 到 HDFS 上 后 ， 任 何 





口 作业 文 伯 
目录 中 使 用 ， 因 而 可 看 作 一 种 非常 简便 的 文件 共享 方式 。 










































































站 来 的 几 节 中 ， 我 们 将 详细 分 析 每 个 步 又 中 涉及 的 技术 细节 。 


5.2 ”作业 提交 过 程 详解 


























在 第 3 章 中 ， 我 们 介绍 了 Hadoop 提 供 的 三 种 应 用 程序 开发 方法 ， 包 括 原始 Java API Hadoop Streaming 和 Hadoop Pipes， 考 虑 到 
后 两 种 方法 的 底层 实际 上 均 调 用 了 Java API， 因 此 ， 在 本 节 中 ， 我 们 以 Java MapReduce 程 序 为 例 讲解 作业 提交 过 程 。 















































5.2.1 执行 Shell 命 令 





























假设 用 户 采 用 Java 语 言 编写 了 一 个 MapReduce 程 序 ， 并 将 其 打包 成 xxx.jar， 然 后 通过 以 下 命令 提交 作业 : 


























$HADOOP HOME/bin/hadoop jar xxx.jar\ 
-D mapred.job.name="xxx"\ 

-D mapred.reduce.tasks=2\ 
-files=blacklist.txt, whitelist.txt\ 
-libjars=third-party.jar\ 
-archives=dictionary.zip\ 
-input/test/input\ 
-output/test/output 

















当 用 户 输入 以 上 命令 后 ，binhadoop 脚 本 根据 ar' 俞 令 将 作业 交 给 RunJar 类 处 理 ， 相 关 shel 代 码 如 下 : 











elif ["SCOMMAND"="jar"]; then 
CLASS=org.apache.hadoop.util.RunJar 








RunJar 类 中 的 Pain 函数 经 解压 jar 包 和 设置 环境 变量 后 ， 将 运行 参数 传递 给 MapReduce 程 序 ， 并 运行 之 。 
































j 户 的 MapReduce 程 序 已 经 配置 了 作业 运行 时 需要 的 各 种 信息 《〈 如 Mapper 类 ，Reducer 类 ，Reduce Task 个 数 等 ) ， 它 最 终 在 
main 函 数 中 调用 JobClentrunJob 函 数 〈 新 MapReduce API 则 使 用 job.waitForCompletion (true) RO 提交 作业 ， 这 之 后 会 依次 经 过 图 
5-2 所 示 的 函数 调用 顺序 才 会 将 作业 提交 到 JobTracker 端 。 


















































JobClient 类 JobTracker 类 


runJob(job) 


invoke 
submitJob() 


submitJob(job) 


invoke 


submitJobInternal(job) 





图 5-2 作业 提交 过 程 中 函数 调用 关系 





5.2.2 ”作业 文件 上 传 

















JobClent 将 作业 提交 到 JobTracker 端 之 前 ， 需 要 进行 一 些 初 始 化 工作 ， 包 括 : 获取 作业 ID， 创 建 HDFS 目 录 ， 上 传 作业 文件 以 
及 生成 Splt 文 件 等 。 这 些 工作 由 函数 JobClient.submitJobInternal (job) 实现 ， 有 具体 流程 如 图 $-3 所 示 。 在 本 小 节 中 ， 我 们 将 重点 分 析 
文件 上 传 过 程 ， 而 生成 InputSpkt 文 件 的 相关 细节 将 放 在 下 一 小 节 中 讨论 。 


JobClient JobTracker HDFS 


getNewJobld() 


jobld i 


mkdirs() 
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i copyRemoteFiles() 4 
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writeSplits() 
1 1 


[ writeXml( ) 


i submitJob(job) 
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图 5-3 作业 提交 过 程 时 序 图 















































MapReduce 作 业 文 件 的 上 传 与 下 载 是 由 DistributedCache 工 具 完 成 的 。 它 是 Hadoop 为 方便 用 户 进行 应 用 程序 开发 而 设计 的 数据 
分 发 工具 。 其 整个 工作 流程 对 用 户 而 言 是 透明 的 ， 也 就 是 说 ， 用 户 只 需 在 提交 作业 时 指定 文件 位 置 ， 至 于 这 些 文件 的 分 发 〈 需 广 
播 到 各 个 TaskTracker 上 以 运行 Task) ， 完 全 由 DistributedCache 工 具 完成 ， 不 需要 用 户 参 与 。 本 小 节 主 要 涉及 文件 上 传 过 程 ， 而 文 
件 下 载 的 相关 细节 将 在 5.4 节 中 介绍 。 















































































































































通常 而 言 ， 对 于 一 个 典型 的 Java MapReduce 作 业 ， 可 能 包含 以 下 资源 。 














口 程序 jar 包 : 用 户 用 Java 编 号 的 MapReduce 应 用 程序 jar 包 。 














口 作业 配置 文件 ， 描述 MapReduce 应 用 程序 的 配置 信息 《根据 JobConf 对 象 生 成 的 xm 文件 





VY 
o 























口 依赖 的 第 三 方 jar 包 : DL RRR ROMS = jart, $222 (ELIS BS Be“ libjars HE » 























口 依赖 的 归档 文件 : 应 用 程序 中 用 到 多 个 文件 ， 可 直接 打包 成 归档 文件 《通常 为 一 些 压 缩 文 件 ) ， 提 交 作 业 时 用 参数 “< 


archives tf 3€ - 

































































口 依赖 的 普通 文件 ， 应 用 程序 中 可 能 用 到 普通 文件 ， 比 如 文本 格式 的 字典 文件 ， 提 交 作 业 时 用 参数 “files" 指 定 。 
























































注意 ”应 用 程序 依赖 的 文件 可 以 存放 在 本 地 磁盘 上 ， 也 可 以 存放 在 HDFS 上 ， 默 认 情 况 下 是 存放 在 本 地 磁盘 上 的 ， 如 上 一 小 
节 中 作业 提交 命令 参数 “libjars=third-party.jar 指 定 的 third-party.jar 文 件 便 存 在 于 本 地 目录 。 如 果 程 序 依赖 的 文件 已 经 事先 上 传 到 
HDFS 上 ， 比 如 目录 /data/ 中 ， 则 可 以 使 用 参数 “lbjars=hd@: /data/third-partyjar 和 指定 。 



























































上 述 所 有 文件 在 JobClient 端 被 提交 到 HDFS 上 ， 涉 及 的 父 目 录 如 表 5-1 所 示 。 

















表 5-1 





作业 属性 


mapreduce.jobtracker.staging.root.dir 








5.2.1 节 中 MapReduce 作 业 在 HDFS 中 的 目录 组 








作业 文件 在 HDFS 中 涉及 的 父 目 录 


属性 值 


$ {hadoop.tmp.dir}/mapred/staging 








mapreduce.job.dir ${ mapreduce.jobtracker.staging.root. FA? Sfuser} 的 作业 {jobId} 相关 
dir }/${user}/.staging/$ {jobId} 文件 存放 目录 


$ {mapreduce.job.dir}/ 











HDFS 上 作业 文件 的 上 传 目录 ， 由 
管理 员 配 置 





织 结构 如 图 5-4 所 示 。 


ANH 





job.splitmetainfo libjars/ 





图 5-4 一 个 应 用 程序 在 HDFS 上 的 目录 组 织 结构 
























































在 这 个 例子 中 ， 由 于 参数 -jbjars，-archives 和 -fles 指 定 的 文件 均 属 于 本 地 文件 ， 因 而 JobClient 会 将 这 些 文件 上 传 到 HDFS 上 ， 如 
果 有 些 文件 已 经 存在 于 HDFS 上 ， 则 不 再 需要 上 传 。 








文件 上 传 完 毕 后 ， 会 将 这 些 目录 信息 保存 到 作业 配置 对 象 JobConft 中 ， 其 对 应 的 作业 属性 如 表 5-2 所 示 。 











表 5-2 
作业 属性 
mapred.cache.files 
mapred.job.classpath.archives 
mapred.cache.archives 


mapreduce.job.cache. files. visibilities 
mapreduce.job.cache.archives. visibilities 


mapred.cache.files.timestamps 
mapred.cache.archives.timestamps 
mapred.cache. files. filesizes 
mapred.cache.archives.filesizes 


mapred.jar 


作业 文件 上 传 后 添加 的 新 配置 选项 


否 


说 明 
作业 依赖 的 普通 文件 在 HDFS 上 的 存放 路 径 
作业 依赖 的 jar 包 在 HDFS 上 的 存放 路 径 
作业 依赖 的 压缩 文件 在 HDFS 上 的 存放 路 径 
作业 依赖 的 普通 文件 的 可 见 性 。 如果 是 public 可 见 性 ， 则 为 true， 
则 为 false 
作业 依赖 的 归档 文件 的 可 见 性 。 如 果 是 public 级 别 的 可 见 性 ， 则 为 


true, “Pill 4) false 


作业 依赖 的 普通 文件 的 最 后 一 次 修改 时 间 的 时 间 惟 
作业 依赖 的 压缩 文件 的 最 后 一 次 修改 时 间 的 时 间 玲 
作业 依赖 的 普通 文件 的 大 小 

作业 依赖 的 归档 文件 的 大 小 

用 户 应 用 程序 jar 路 径 





DistributedCache 将 文件 分 为 两 种 可 见 级 别 ， 分 别 是 private 级 别 和 public 级 别 。 其 中 ，private 级 别 文件 只 会 被 当前 用 户 使 用 ， 不 能 
与 其 他 用 户 共享 ， 而 public 级 别 文件 则 不 同 ， 它 们 在 每 个 节点 上 保存 一 份 ， 可 被 本 节点 上 的 所 有 作业 和 用 户 共享 ， 这 样 可 以 大 大 降 
低 文件 复制 代价 ， 提 高 了 作业 运行 效率 。 一 个 文件 /目录 要 成 为 public 级 别 文件 /目录 ， 需 同时 满足 以 下 两 个 条 件 : 















































口 该 文件 /目录 的 父 目录 、 父 目录 的 父 目 录 


























口 该 文件 /目录 对 所 有 用 户 / 用 户 组 均 有 可 读 权限 。 





对 所 有 用 户 / 用 户 组 有 可 执行 权限 。 











作业 文件 上 传 到 HDFS 后 ， 可 能 会 有 大 量 节点 同时 从 HDFS 上 下 载 这 些 文件 ， 进 而 产生 文件 访问 热点 现象 ， 造 成 性 能 瓶颈 。 为 














E 








此 ，JobClient 上 传 这 些 文件 时 会 调 





局 es 们 的 























访问 热点 。 


H] 


副本 数 〈 由 参数 mapred.submitreplcation 指 定 ， 默 认 是 10) 以 通 























过 分 挫 负 载 方式 避免 产生 


5.2.3 产生 InputSplit 文 件 


f 























上 后 ，JobClient 会 调 
以 生成 Task 本 地 | 











户 提交 MapReduce 作 记 
PF， 第 一 部 分 将 被 JobTracker 使 
两 部 分 信息 分 别 被 保存 到 
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InputSplt 相 关 操作 放 在 包 org.apache.hadoop.mapreduce.split 





<<interface>> 
Writable 


InputFormat 的 getSplits 方 法 和 


录 $ {mapreduce.jobtracker.staging, root. dir} /$ {user} /.staging/$ {JobId} F K 3¢ (Fjob.splitflljob. splitmetainfo4 














E 成 InputSplt 相 关 信 息 。 该 信息 包括 两 部 分 : InputSphitc Bia SA 
Pe (Task Locality) 相关 的 数据 结构 ， 而 了 分 则 将 被 Map Task 初 始 化 时 使 Wy 
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[原始 InputSplt 信 息 。 
取 自 己 要 处 理 的 数据 。 这 
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图 














要 





包含 三 个 类 JobSplt、JobSplitWriter 和 SplitMetaInfoReader。 它 们 


的 关系 如 








5-5 所 示 。 








JobSplitWriter 


+writeSplitHeadefin out : FSDataOutputStream) 
+writeNewSplitgin conf : Configuration, in array: T[], in out : FSDataOutputStream) : JobSplit.SplitMetaInfo[] 


+writeOldSplitsin splits : InputSplit, in out ; FSDataOutputStream in conf : Configuration) : JobSplit.SplitMetaInfo 
+writeJobSplitMetalnfo(in fs : FileSystem, in filename : Path, in p : FsPermission, in splitMetaInfoVersion : int, in ...) 





JobSplit | 




















SplitMetalnfoReader 








NZ 











JobSplit. TaskSplit Index 




















+readSplitMetalnfo(in jobId : JobID, in fs : FileSystem, in conf : Configuration, in jobSubmitDir : Path) : JobSplit.TaskSplitMetaInfo 
























































图 5-5 ”InputSplt 类 关系 图 
JobSplt 封 装 了 读 写 InputSptt 相 关 的 基础 类 ， 主 要 包括 以 下 三 个 。 
口 SplitMetaInfo: 描述 一 个 InputSptt 的 元 数据 信息 ， 包 括 以 下 三 项 内 容 : 
private long startOffset; // 该 InputSplit 元 信息 在 job.split 文 件 中 的 偏 移 量 
private long inputDataLength; // 该 InputSplit 的 数据 长 度 
private String[]locations; // 该 InputSplit 所 在 的 host 列 表 
所 有 InputSpit 对 应 的 SpltMetaInfo 将 被 保存 到 文件 job.splitmetainfp 中 。 该 文件 内 容 组 织 方 式 如 图 $-6 所 示 ， 内 容 依次 为 : 一 个 用 于 标识 InputSpt 元 数据 文件 头 部 的 字符 





META-SP”， 文 件 版 本 号 spitVersion 〈 当 前 值 是 1) ， 





作业 在 JobTracker 端 初始 化 时 ， 需 读 取 job.splitmetainfo 文 件 包 




















Q TaskSplitMetalnfo: 




















lil 





作业 对 应 的 InputSplit 数 目 length， 最 后 是 length 个 InputSplt 对 应 的 SpltMetamfo 


aid 





o 













META-SP splitVersion 
SplitMetaInfo 


SplitMetaInfo 




















图 5-6 job.spltmetainfo 文 件 内 容 组 织 方式 
建 Map Task， 具 体 参 考 5.3 节 。 


于 保存 InputSplt 元 信息 的 数据 结构 ， 包 括 以 下 三 项 内 容 : 





private TaskSplitIndex splitIndex; //Split 元 信 





言 息 在 job . split 文 件 中 的 位 置 


private long inputDataLength; //InputSplit 的 数据 长 度 
private String[]locations; //InputSplit 所 在 的 host 列 表 





这 些 信 息 是 在 作业 初始 化 时 ，JobTracker 从 文件 job.splitmetainfo 吕 


保存 了 新 人 各 
任务 。 





F 务 需 处 理 的 数据 位 置信 息 在 文件 job.splt 














QTaskSplitIndex: JobTracker 向 TaskTracker 分 配 新 各 


P 的 索引 ，TaskTracker (从 JobTracker 端 ) 收 到 该 信息 后 ， 便 可 以 从 job.splt 文 件 























获取 的 。 其 中 ，host 列 表 信息 是 各 





F 务 调度 器 判断 任务 是 否 具 有 本 地 性 的 最 寻 








大 | 





素 ， 而 splitIndex 信 息 
P 读 取 InputSptt 信 息 ， 进 而 运行 一 个 新 


ET 









































SS 
zi 








于 指定 新 人 








E 要 包括 两 项 内 容 : 











E 务 时 ，TaskSplitIndex/ E 务 待 处 理 数据 位 置信 息 在 文件 job.spkt 中 的 索引 ，3 





private String splitLocation; //job.split 文 件 


private long startOffset: //InputSplit 信 息 在 job.split 文 件 





的 位 置 (目录 ) 





FP 的 位 置 





5.2.4 ”作业 提交 到 JobTracker 











JobClient 最 终 调用 RPC 方 法 submitJob 将 作业 提交 到 JobTracker 端 ， 在 JobTracker.submitJob 中 ， 会 依次 进行 以 下 操作 : 














(1) 为 作业 创建 JobInProgress 对 象 














yE 


























JobTracker 会 为 每 个 作业 创建 一 个 JobInProgress 对 象 。 该 对 象 维护 了 作业 的 运行 时 信息 。 它 在 作业 运行 过 程 中 一 直 存在 ， 主 
j 于 跟踪 正在 运行 作业 的 运行 状态 和 进度 。 















































(2) 检查 用 户 是 否 具有 指定 队列 的 作业 提交 权限 


















































Hadoop 以 队列 为 单位 管理 作业 和 资源 ， 每 个 队列 分 配 有 一 定量 的 资源 ， 每 个 用 户 属于 一 个 或 者 多 个 队列 且 只 能 使 用 所 属 队 
列 中 的 资源 。 第 4 章 中 提 到 ， 管 理 员 可 为 每 个 队列 指定 哪些 用 户 具有 作业 提交 权限 和 管理 权限 。 
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(3) 检查 作业 配置 的 内 存 使 用 
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j 户 提交 作业 时 ， 可 分 别 用 参数 mapred.job.map.memoryImb 和 mapred.job.reduce.memory.mb 指 定 Map Task 和 Reduce Task 占 用 的 内 
; 而 管理 员 可 通过 参数 mapred.cluster.max.map.memory.nb 和 mapred.cluster.max.reduce.memory.mb 限 制 用 户 配置 的 任务 最 大 内 存 使 
且 用 户 配置 的 内 存 使 用 量 超过 系统 限制 ， 则 作业 提交 失败 。 
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(4) 通知 TaskScheduler 初 始 化 作业 












































JobTracker 收 到 作业 后 ， 并 不 会 马上 对 其 初始 化 ， 而 是 交 给 调度 器 ， 由 它 按照 一 定 的 策略 对 作业 进行 初始 化 。 之 所 以 不 选择 
JobTracker 而 让 调度 器 初始 化 ， 主 要 考虑 到 以 下 两 个 原因 : 









































口 作 业 一 旦 初始 化 后 便 会 占用 一 定量 的 内 存 资 源 ， 为 了 防止 大 量 初始 化 的 作业 排队 等 待 调度 而 占用 大 量 不 必要 的 内 存 资 
源 ，Hadoop 按 照 一 定 的 策略 选择 性 地 初始 化 作业 以 节省 内 存 资 源 ; 




































































口 任务 调度 器 的 职责 是 根据 每 个 节点 的 资源 使 用 情况 对 其 分 配 最 合适 的 任务 ， 而 只 有 经 过 初始 化 的 作业 才 有 可 能 得 到 调度 ， 
而 将 作业 初始 化 策略 谋 到 调度 器 中 是 一 种 比较 合理 的 设计 。 
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Hadoop 的 调度 器 是 一 个 可 插 拔 模块 ， 用 户 可 通过 实现 TaskScheduler 接 口 设 计 自己 的 调度 器 。 当 前 Hadoop 默 认 的 调度 器 是 
JobQueueTaskScheduler。 它 采用 的 调度 策略 是 先 来 先 服务 (First In First Out, FIFO) 。 另 外 两 个 比较 常用 的 调度 器 是 Fair Scheduler 和 
Capacity Scheduler， 上 有 具体 参考 第 10 章 。 

































































JobTracker 采 用 了 观察 者 设计 模式 〈 也 称 为 发 布 -订阅 模式 ) 将 “提交 新 作业 "这 一 事件 告诉 TaskScheduler， 如 图 5-7 所 示 。 




















Subject Observer 





EagerTaskInitializationListener 
notify (obAdded/jjobRemovedjobUpdated) 


JobQueueTaskScheduler 


JobTracker 
addJobInProgressListener 
removeJobInProgressListener 
updateJobInProgressListeners 


notify ‘ 
JobQueueJobInProgressListener 


(jobAdded/jobRemoved/jobUpdated) 











图 5-7 JobTracker 采 用 观察 者 设计 模式 将 作业 变化 〈 添 加 /删除 /更 新 作业 ) 通知 TaskScheduler 
































JobTracker 采 用 了 观察 者 设计 模式 将 “提交 新 作业 ”这 一 事件 告诉 TaskScheduler 的 相关 代码 如 下 : 








private synchronized JobStatus addJob (JobID jobId, JobInProgress job) 
throws IOException { 


synchronized (jobs) { 

synchronized (taskScheduler) { 

jobs.put (job.getProfile().getJobID(), job) ; 

for (JobInProgressListener listener: jobInProgressListeners) { 
listener. jobAdded (job) ; // 依 次 通知 每 个 已 注册 的 JobInProgressListener 




















JobTracker 启 动 时 会 根据 配置 参数 mapred.jobtracker.taskScheduler 构 造 相 应 的 任务 调度 器 ， 并 调用 它 的 start0 方 法 进行 初始 化 。 

















在 该 方法 中 ， 调 度 器 会 向 JobTracker 注 册 JobInProgressListener 对 象 以 监听 作业 的 添加 /删除 /更 新 等 事件 。 以 默认 调度 器 
JobQueueTaskScheduler 为 例 ， 它 的 start0 方 法 如 下 : 





public synchronized void start()throws IOException{ 

super.start(); 

// 此 处 的 LaskTrackerManager 实 际 上 就 是 JobTracker 对 象 ， 向 JobTracker 注 册 一 个 
//JobQueueJobInProgressListener 

taskTrackerManager.addJobInProgressListener (jobQueueJobInProgressListener) ; 
eagerTaskInitializationListener.setTaskTrackerManager (taskTrackerManager) ; 
eagerTaskInitializationListener.start (); 
//\\JobTrackerit#tEagerTaskiInitializationListener 
taskTrackerManager.addJobInProgressListener ( 
eagerTaskInitializationListener) ; 


} 


























在 上 面 的 代码 中 ，JobQueueTaskScheduler 向 JobTracker 注 册 了 两 个 JobInProgress Listener: EagerTaskInitializationL istener#ll 
JobQueueJobInProgressListener， 它 们 分 别 用 于 作业 初始 化 和 作业 排序 (具体 参考 第 10 章 ) 。 需 要 注意 的 是 ， 代 码 中 的 
taskTrackerManager 实 际 上 就 是 JobTracker， 其 在 JobTracker 类 中 的 相关 代码 如 下 : 






































public static JobTracker startTracker (JobConf conf, String identifier) 
throws IOException, InterruptedException{ 


result=new JobTracker (conf, identifier) ; // 创 建 唯一 的 JobTracker 实 例 
result.taskScheduler.setTaskTrackerManager (result) ; // 将 JobTracker 实 例 传递 给 TaskScheduler 








5.3 ”作业 初始 化 过 程 详 解 











调度 器 调用 JobTracker.iniUob0 函 数 对 新 作业 进行 初始 化 。 作 业 初 始 化 的 主要 工作 是 构造 Map Task 和 Reduce Task 并 对 它们 进行 初始 
化 。 


如 图 $-8 所 示 ，Hadoop 将 每 个 作业 分 解 成 4 种 类 型 的 任务 ， 分 别 是 Setup Task, Map Task, Reduce Task 和 Cleanup Task。 它 们 的 运行 时 信 
息 由 TaskInProgress 类 维护 ， 因 此 ， 创 建 这 些 任务 实际 上 是 创建 TaskInProgress 对 象 。 











(Job Status) 
JobInProgress ' 
‘<PREP> 
TaskInProgress TaskInProgress |; ° 
(Map Setup Task) || (Reduce Setup Task) ' 
a | 
多 
: 
PR: TaskInProgress| | TaskInProgress| __ S ssi i 
=> ; (Map Task) (Map Task) í 
6. : <RUNNING> 
EE i 
3 : 
TaskInProgress TaskInProgress 
(Map Cleanup Task) (Reduce Cleanup Task) 
e 
Ask For Y<SUCCEEDED> 
New Task 


图 5-8 作业 初始 化 过 程 概述 


上 述 4 种 任务 的 作用 及 创建 过 程 如 下 。 



































口 Setup Task: 作业 初始 化 标识 性 任务 。 它 进行 一 些 非常 简单 的 作业 初始 化 工作 ， 比 如 将 运行 状态 设置 为 “setup”， 调 用 
OutputCommitter.setupJob0 函 数 等 。 该 任务 运行 完 后 ， 作 业 由 PREP 状 态 变 为 RUNNING 状 态 ， 并 开始 运行 Map Task。 该 类 型 任务 又 被 分 为 
Map Setup Task 和 Reduce Setup Task 两 种 ， 且 每 个 作业 各 有 一 个 。 它 们 运行 时 分 别 占 用 一 个 Map slot 和 Reduce slot。 由 于 这 两 种 任务 功能 
同 ， 因 此 有 且 只 有 一 个 可 以 获得 运行 的 机 会 ( 即 只 要 有 一 个 开始 运行 ， 另 一 个 马上 被 杀 掉 ， 而 具体 哪 一 个 能 够 运行 ， 取 决 于 当时 存在 的 
空闲 slot 种 类 及 调度 策略 ) 。 
















































































创建 该 类 任务 的 相关 代码 如 下 : 








/ /创建 两 个 TTP，Map 和 Reduce 各 一 个 

setup=new TaskInProgress[2]; 

//setup map tip. 这 个 Map 不 会 使 用 任何 split， 只 赋予 它 一 个 空 split 
setup[0]=new TaskInProgress (jobId, jobFile, emptySplit, 
jobtracker, conf, this, numMapTasks+1, 1) ; 


























Setup [0] .setJobSetupTask (); 
//setup reduce tip. 

setup [1]=new TaskInProgress (jobId, jobFile, numMapTasks, 
numReduceTasks+1, jobtracker, conf, this, ; 

setup[1] .setJobSetupTask (); 









































口 Map Task: Map 阶 段 处 理 数 据 的 任务 。 其 数 a Pr I 











及 对 应 的 处 理 数 ] 





应 用 程序 中 的 InputFonmat 组 件 确定 。 











创建 该 类 任务 的 相关 代码 如 下 : 











// 读 取 job.splitmetainfo 文 件 ， 还 原 TaskSplitMetaInfo 对 象 ， 每 个 对 象 描述 
TaskSplitMetaInfo[]splits=createSplits (jobId) ; 
numMapTasks=splits.length; 


了 一 个 InputSplit 信 息 





maps=new TaskInProgress [numMapTasks]; 

for (int i=0; i<numMapTasks; ++i) { 
inputLengtht=splits[i].getInputDataLength () ; 
maps [i]=new TaskInProgress (jobId, jobFile, 
splits [i], 

jobtracker, conf, this, i, numSlotsPerMap) ; 
} 



























































































































































口 Reduce Task: Reduce 阶 段 处 理 数 据 的 任务 。 其 数目 由 用 户 通过 参数 mapred.reduce.tasks〈 默 认 数目 为 1) 指定 。 考 虑 到 Reduce Task 能 
否 运行 依赖 于 Map Task 的 输出 结果 ， 因 此 ，Hadoop 刚 开始 只 会 调度 Map Task， 直 到 Map Task 完 成 数目 达到 一 定 比例 〈 由 参数 
mapred.reduce.slowstartcompleted.maps 指 定 ， 默 认 是 0.05， 即 35%) 后 ， 才 开始 调度 Reduce Task. 

创建 该 类 任务 的 相关 代码 如 下 : 

this.reduces=new TaskInProgress [numReduceTasks]; 

for (int i=0; i<numReduceTasks; i++) { 

reduces[i]=new TaskInProgress (jobId, jobFile, 

numMapTasks, i, 

jobtracker, conf, this, numSlotsPerReduce) ; 

nonRunningReduces.add (reduces [i]) 

口 Cleanup Task: 作业 结束 标志 性 任务 ， 主 要 完成 一 些 作 业 清 理工 作 ， 比 如 删除 作业 运行 过 程 中 用 到 的 一 些 临时 目录 〈 比 如 























_temporary 目 录 ) 。 一 旦 该 任务 运行 成 功 后 ， 作 业 由 RUNNING 状 态 变 为 SUCCEEDED 状 态 。 











E 业 执行 进度 且 降 低 作 业 的 可 靠 性 由 
对 于 Map/Reduce Task 而 言 ， 可 通过 








随 着 Hadoop 的 普及 和 衍化， 有 人 发 现 引 入 Setup/Cleanup Task 会 拖 慢 4 
需 保证 每 个 Map/Reduce Task 运 行 成 功 外 ， 还 要 保证 Setup/Cleanup Task 成 功 。 
6.6 节 ) 避免 出 现 '“ 移 后 腿 ?" 性 务 。 然 而 ， 由 于 Setup/Cleanup Task 不 会 处 理 任 何 数 据 ， 两 种 生 
















































































， 这 主要 是 因为 Hadoop 除 了 
推测 执行 机 制 〈 且 
E 务 进度 只 有 0% 和 100% 两 个 值 ， 从 而 使 得 推测 式 





体 参考 





























任务 机 制 对 之 不 适用 。 为 解决 该 问题 ， 从 0.21.0 版 本 开始 ，Hadoop 将 是 否 启用 Setup/Cleanup Task 变 成 了 可 配置 的 选项 口 ， 


























j 户 可 通过 参 





























数 mapred.committer,job.setup.cleanup.needed 配 置 是 否 为 作业 创建 Setup/Cleanup Task. 






































这 4 种 任务 的 调度 顺序 是 Setup Task. Map Task, Reduce Task 和 Cleanup Task, H, Map Task 完 成 一 定 比例 后 便 开 始 调 
Task。 这 期 间 涉 及 一 些 任务 调度 策略 ， 我 们 将 在 第 6 章 中 详细 讨论 。 

















[1] httpsVissues. apache. org/jira/browse/MAPREDUCE- 1099 
[2] https//issues. apache. org/jira/browse/ MAPREDUCE-463 

















| Reduce 


5.4 Hadoop DistributedCache 原 理 分 析 


的 


JobTracker 文 伯 
外 ，DistributedCache 还 可 月 












































DistriputedCache 是 Hadoop 为 方便 用 户 进行 应 用 程序 开发 而 设计 的 文件 分 发 工具 。 它 能 够 将 只 读 的 外 部 文件 自动 分 发 到 各 个 节 
点 上 进行 本 地 缓存 ， 以 便 Task 运 行 时 加 载 使 用 。 它 的 大 体 工作 流程 如 下 : 用 户 提交 作业 后 ，Hadoop 将 由 -fles 和 -archives 选 项 指定 
系统 〈 一 般 为 HDFS) 中 ; 之 后 ， 当 某 个 TaskTracker 收 到 该 作业 的 第 一 个 Task 后 ， 该 任务 将 负责 从 
载 到 本 地 磁盘 进行 缓存 ， 这 样 后 续 的 Task 就 可 以 直接 在 本 地 访问 这 些 文件 了 。 除 了 文件 分 发 





文件 复制 到 JobTracker 的 文件 
系统 中 将 文件 下 
































员 进 行 一 次 升级 ， 这 使 得 软 伯 


各 个 节点 上 ， 每 次 运行 程序 时 ， 


5.4.1 

































































使 用 方法 介绍 


j 户 编写 的 MapReduce 应 月 



























































































































































本 节 首 先 介绍 Hadoop DistributedCache 使 用 场景 和 使 用 方法 ， 接 着 介绍 其 工作 原理 。 































































































程序 分 


























们 希望 每 个 Task 初 始 化 时 能 够 加 载 这 些 文件 ， 而 DistributedCache 正 是 为 了 完成 该 功能 而 提供 的 。 



































(1) 调用 相关 API 
































使 用 Hadoop DistributedCache 通 常 有 两 种 方法 : 调用 相关 API 和 设置 命令 行 参数 。 
































于 软件 自动 安装 部 署 。 比 如 ， 用 户 使 用 PHP 语 言 编写 了 MapReduce 程 序 ， 为 了 能 够 让 程序 成 功 运行 ， 
j 户 需要 求 运 维 人 员 在 Hadoop 集 群 的 各 个 节点 上 提前 安装 好 PHP 解 释 器 ， 而 当 需 要 升级 PHP 解 释 器 时 ， 可 能 需 通知 Hadoop 运 维 人 
F 升 级 变 得 非常 麻烦 。 为 了 让 软件 升级 变 得 更 可 控 ， 用 户 可 采用 DistributedCache 将 PHP 解 释 器 分 发 到 


DistributedCache 会 检查 PHP 解 释 器 被 改过 〔 比 如 升级 新 版 本 ) ， 如 果 是 ， 则 会 自动 重新 下 载 。 





往 需要 一 些 外 部 的 资源 ， 比 如 分 词 程序 需 词 表 文 件 ， 或 者 依赖 于 三 方 的 jar 包 。 这 时 候 ， 我 


Hadoop DistributedCache 允 许 用 户 分 发 归档 文件 (后 缀 为 .加 、.jar、.tar、.tgz 或 者 .tar.gz 的 文件 ) 和 普通 文件 ， 对 应 的 API 如 下 : 














/ /添加 归档 文件 


void addCacheArchive (URI uri, Configuration conf) 
void setCacheArchives (URI [Jarchives, Configuration conf) 


// 添 加 普通 文件 


void addCacheFile (URI uri, Configuration conf) 

void setCacheFiles (URI[]files, Configuration conf) 

或 者 动态 库 添加 到 classpath 中 

void addFileToClassPath (Path file, Configuration conf) 
EF 录 下 建立 文件 软 连 接 


void createSymlink (Configuration conf) 











// 将 三 方 jar 包 





// 在 任务 
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步骤 3 在 Mapper 或 者 Reducer 类 中 使 用 文件 ，Mapper 或 者 Reducer 开 始 运行 前 ， 各 种 文件 已 经 下 载 到 本 地 的 工作 























j 相 关 API 添 加 文件 信息 ， 这 里 


| Hadoop DistributedCache 可 分 为 3 个 步 又 : 

































































要 是 配置 作业 的 JobConf 对 象 ; 


in 








步骤 1 在 HDFS 上 准备 好 文件 〈 文 本 文件 、 压 缩 文件 、jar 包 等 ) ， 并 按照 文件 可 见 级 别 设置 目录 /文件 的 访问 权限 ; 















































KA, 


直接 








文件 读 写 API 即 可 获取 文件 内 容 。 





























【实例 】 假 设 一 个 MapReduce 应 用 程序 需要 dictionary.zip、blacklisttxt、whitelisttxt 和 third-partyjar 四 个 文件 ， 其 中 ，dictionary.zip 
和 third-partyjar 为 private 可 见 级 别 ， 而 blacklisttxt 和 whitelsttxt 为 public 可 见 级 别 ， 则 可 按 以 下 步骤 分 发 这 些 文件 : 


步骤 1 HEC 


录 /data/public/ 中 。 








Fo ESCH 








F dictionary. zip Fil third-party jar_. 4% 4) HDFS_- (J H 3K/data/private/F ,  blacklist.txt#l whitelist. txt 
其 中 ， 目 录 /data/private/ 的 权限 为 “drwxr-xr--”， 目 录 /data/public/ 的 权限 为 “drwxr-xr-x”。 





KEEN) 




















$bin/hadoop 
$bin/hadoop 
$bin/hadoop 
$bin/hadoop 


fs-copy 
fs-copy. 
fs-copy 


From] 
From] 
From] 





fs-copy 


Local dictionary.zip/data/private/ 
Local third-party.jar/data/private/ 
Local blacklist.txt/data/public/ 





From] 


Local whitelist.txt/data/public/ 





步骤 2 ”配置 JobConf. 








JobConf job=new JobConf (); 


DistributedCache. 
DistributedCache. 
DistributedCache. 
DistributedCache. 
DistributedCache. 


addCacheFile (new URI ("/data/public/blacklist.txt#blacklist") , job) ; 
addCacheFile (new URI ("/data/public/whitelist.txt#whitelist", job) ; 
addFileToClassPath (new Path ("/data/private/third-party.jar") , job) ; 
addCacheArchive (new URI ("/data/private/dictionary.zip", job) ; 
createSymlink (job) ; 








步骤 3 ”在 Mapper 或 者 Reducer 类 中 使 用 文件 。 





























public static class MapClass extends MapReduceBase 
implements Mapper<K, V, K, V>{ 

private Path[]localArchives; 

private Path[]localFiles; 

public void configure (JobConf job) { 

// 在 本 地 获取 archives 或 者 files 
localArchives=DistributedCache.getLocalCacheArchives (job) ; 
localFiles=DistributedCache.getLocalCacheFiles (job) ; 























// 调 用 文件 API 读 取 文 件 内 容 ， 保 存 到 相关 变量 中 








public void map (K key, V value, 
OutputCollector<K, V>output, Reporter reporter) 
throws IOException { 

/ /在 此 使 用 缓存 中 的 archives/files 























output.collect (k, v); 


} 
} 





(2) 设置 命令 行 参 数 



































这 是 一 种 比较 简单 且 灵 活 的 方法 ， 但 前 提 是 用 户 编写 MapReduce 应 用 程序 时 实现 了 Too 隘 口 支持 常规 选项 。 该 方法 包括 两 
步骤 ， 其 中 第 一 个 步骤 与 “调用 相关 APT 的 步骤 1 相同 ， 而 第 二 个 步骤 则 是 使 用 以 下 两 种 Shel 命 令 之 一 提交 作业 。 


Shells 4 1: 






































SHADOOP HOME/bin/hadoop jar xxx.jar\ 

-files=hdfs: ///data/public/blacklist.txt#blacklist, \ 
hdfs: ///data/public/whitelist.txt#whitelist\ 
-libjars=hdfs: ///data/private/third-party.jar\ 
-archives=hdfs: ///data/private/dictionary.zip\ 





Shells 4 2: 





SHADOOP_HOME/bin/hadoop jar xxx.jar\ 

-D mapred.cache.files=/data/public/blacklist.txt#blacklist, \ 
/data/public/whitelist.txt#whitelist\ 

-D mapred.cache.archives=/data/private/dictionary.zip\ 

-D mapred.job.classpath.files=/data/private/third-party.jar\ 
-D mapred.create.symlink=yes\ 





5.4.2 ”工作 原理 分 析 











Hadoop DistributedCache 工 作 原 理 如 图 $-9 所 示 。 它 主要 的 功能 是 将 作业 文件 分 发 到 各 个 TaskTracker 上 ， 有 具体 流程 可 分 为 4 个 步骤 : 
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图 5-9 Hadoop DistributedCache 工 作 原理 图 











步 又 1 用 户 提 交 作业 后 ，DistributedCache 将 作业 文件 上 传 到 HDFS 上 的 固定 目录 中 ， 具 体 见 5.2.2 节 。 





步骤 2 ”JobTracker 端 的 任务 调度 器 将 作业 对 应 的 任务 发 派 到 各 个 TaskTracker 上 。 





























步骤 3 任何 一 个 TaskTracker 收 到 该 作业 的 第 一 个 任务 后 ， 由 DistributedCache 自 动 将 作业 文件 缓存 到 本 地 目录 下 (对 于 后 级 为 .zp、.jar、 
.tar、.tgz 或 者 .tar.gz 的 文件 ， 会 自动 对 其 进行 解压 缩 》， 然 后 开始 启动 该 任务 。 












































步骤 4 ”对 于 TaskTracker 接 下 来 收 到 的 任务 ，DistributedCache 不 会 再 重复 为 其 下 载 文 件 ， 而 是 直接 运行 。 












































下 面 分 析 TaskTracker 中 作业 目录 组 织 结构 ， 具 体 如 图 5-10 所 示 。 在 TaskTracker 本 地 目录 中 ， 不 同 可 见 级 别 的 文件 被 存放 于 不 同 的 目录 。 
对 于 public 级 别 的 文件 ， 会 被 保存 到 公共 目录 $f{mapred.localdir}/taskTracker/distcache 中 ， 该 目录 中 的 文件 可 被 该 TaskTracker 上 所 有 用 户 共享 ， 
也 就 是 说 ， 这 些 文件 只 会 被 下 载 一 遍 ， 后 面 的 任何 用 户 的 作业 可 直接 使 用 ， 对 于 private 级 别 的 文件 ， 则 被 保存 到 用 户 私 有 目录 









































































































































${mapred.local.dir}/taskTracker/$ {user} 下， 在 该 目录 下 ， 将 DistributedCache 文 件 和 作业 运行 需要 文件 分 别 放 到 子 目 录 distcache 和 jobcache 中 ， 殿 
中 jobcache 目 录 相 当 于 作业 的 工作 目录 ， 它 里 面 的 文件 大 多 是 指向 其 他 文件 和 目录 的 软 连 接 ， 这 些 目录 中 的 文件 只 能 被 该 用 户 的 作业 共享 。 
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图 5-10 ”TaskTracker 端 作业 目录 组 织 结构 





























DistributedCache 中 的 文件 或 者 目录 并 不 是 用 完 后 立即 被 清理 的 ， 而 是 由 专门 的 一 个 线程 根据 文件 大 小 上 限 ( 由 参数 localcache.size 设 定 ， 


默认 是 10 GB) 


mapreduce.tasktracker.distributedcache.checkperiod 设 定 ， 默 认 是 60) 地 进行 清理 。 






































和 文件 /目录 数目 上 限 〈 由 参数 mapreduce.tasktracker.localcache.nunberdirectories 设 定 ， 默 认 是 10 000) 周期 性 (由 参数 





Hadoop DistributedCache 的 实现 在 包 org.apache.hadoop.flecache 中 ， 主 要 包括 DistributedCache、TaskDistributedCacheManager 和 
TrackerDistributedCacheManager 三 个 类 。 它 们 的 功能 如 下 。 


















































口 DistributedCache 类 : 可 供用 户 直 接 使 用 的 外 部 类 。 它 提供 了 一 系列 addXXX、setXXX 和 getXXX 方 法 以 配置 作业 需 借 用 DitributedCache 分 


发 的 只 读 文件 。 





























口 TaskDistributedCacheManager 类 : Hadoop 内 部 使 用 的 类 ， 用 于 管理 一 个 作业 相关 的 缓存 文件 。 















































口 TrackerDistributedCacheManager 类 : Hadoop 内 部 使 用 的 类 ， 用 于 管理 一 个 TaskIracker 上 所 有 的 缓存 文件 。 它 只 用 于 缓存 pubic 可 见 级 别 
的 文件 ， 而 对 于 private 可 见 级 别 的 文件 ， 则 由 org.apache.hadoop.mapred 包 中 的 JobLocalizer 类 进行 缓存 。 



































































































































5.5 小结 
作业 提交 与 初始 化 过 程 是 指 从 用 户 输入 提交 作业 命令 到 作业 初始 化 的 整个 过 程 。 该 过 程 涉 及 Hadoop 三 个 非常 重要 的 组 件 ， 
即 JobClent、JobTracker 和 TaskScheduler。 
作业 提交 主要 是 为 后 续 作 业 执 行 准备 环境 ， 涉 及 创建 目录 、 上 传 文件 等 操作 。 
作业 初始 化 的 主要 工作 是 根据 输入 数据 量 和 作业 配置 参数 将 作业 分 解 成 若干 个 Map Task 以 及 Reduce Task， 并 添加 到 相关 数据 














结构 中 ， 以 等 待 后 续 被 调度 执行 。 
































F 发 而 设计 的 数据 分 发 工具 。 它 能 
































日 户 进行 应 用 程序 必 





Hadoop DistributedCache 是 Hadoop 为 方便 月 
各 个 节点 上 进行 本 地 缓存 ， 以 便 Task 和 运行 时 加 载 使 用 。 它 将 待 分 发 的 文 但 
F 允 许 同 一 个 TaskTracker 上 所 有 用 户 共享 ， 而 private 级 别 文件 只 允许 某 个 用 户 










































































中 ，public 级 别 文人 











日 关 数据 结构 中 等 待 被 调度 执行 。 在 下 一 章 








作业 在 JobTracker 端 经 初始 化 后 ， 会 被 存放 到 可 
务 调度 的 相关 原理 及 实现 。 





F 根 据 可 见 级 别 分 为 public 级 别 和 private 级 别 
的 所 有 作业 共享 。 





它 能 够 将 只 读 的 大 文件 自动 分 发 到 

















种 。 其 








章 中 ， 我 们 将 重点 分 析 JobTracker 和 任 





第 6 章 ”JobTracker 内 部 实现 剖析 
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好 坏 » A 








此 ， 它 是 整个 系统 中 








提 到 ，Hadoop MapReduce 采 用 了 MasterSlave 结 构 。 其 中 ，Master 便 是 这 一 章 将 要 讲解 的 JobTracker， 它 是 整个 集群 中 唯一 的 全 局 ' 管 
理 者 ”， 涉 及 的 功能 包括 作业 管理 、 状 态 监 控 、 任 务 调 度 器 等 。 它 的 设计 思路 直接 决定 着 Hadoop MapReduce 计 算 框架 的 容错 性 和 可 扩 
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最 重要 的 组 件 ， 是 系统 高 效 运转 的 关键 。 




















本 章 将 详细 介绍 JobTracker 的 实现 细节 。 总 的 来 看 ，JobTracker 主 要 包含 两 个 功能 : 资源 管理 和 作业 控制 。 本 章 将 以 这 两 个 功能 为 切入 

























































































































































































































































































点 深入 剖析 JobTracker 的 实现 细节 ， 包 括 状态 监控 、 容 错 机 制 、 推 测 执行 原理 和 任务 调度 机 制 等 。 
6.1 JobTracker 概 述 

JobTracker 是 整个 MapReduce 计 算 框 架 中 的 主 服务 ， 相 当 于 集群 的 管理 者 ”负责 整个 集群 的 作业 控制 和 资源 管理 。 在 Hadoop 内 部 ， 每 
个 应 用 程序 被 表示 成 一 个 作业 ， 每 个 作业 又 被 进一步 分 成 多 个 任务 ， 而 JobTracker 的 作业 控制 模块 则 负责 作业 的 分 解 和 状态 监控 。 其 中 ， 最 
重要 的 是 状态 监控 ， 主 要 包括 TaskTracker 状 态 监控 、 作 业 状 态 监控 和 任务 状态 监控 等 。 其 主要 作用 有 两 个 ;容错 和 为 任务 调度 提供 决策 依 
据 。 一 方面 ， 通 过 状态 监控 ，JobTracker 能 够 及 时 发 现存 在 异常 或 者 出 现 故障 的 TaskTracker、 作 业 或 者 任务 ， 从 而 启动 相应 的 容错 机 制 进行 
处 理 ， 另 一 方面 ， 由 于 JobTracker 保 存 了 作业 和 任务 的 近似 实时 运行 信息 ， 这 些 可 用 于 任务 调度 时 进行 任务 选择 的 依据 。 资 源 管理 模块 的 作 
用 是 通过 一 定 的 策略 将 各 个 节点 上 的 计算 资源 分 配给 集群 中 的 任务 。 它 由 可 插 拔 的 任务 调度 器 完成 ， 用 户 可 根据 自己 的 需要 编写 相应 的 调 
度 器 。 


JobTracker 的 设计 原理 如 图 
































6-]1 所 示 。JobTracker 是 一 个 后 台 服 务 进程 ， 启 动 之 后 ， 会 一 直 监 听 并 接收 来 自 各 个 TaskTracker 发 送 的 心跳 信 



































息 ， 这 里 
































看 包含 节点 资源 使 











情况 和 任务 运行 情况 等 信息 。JobTracker 会 将 这 些 信息 统一 保存 起 来 ， 并 根据 需要 为 TaskTracker 分 配 新 任务 。 
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图 6-1 JobTracker 内 部 原理 


(1) 作业 控制 











JobTracker 在 其 内 部 以 “三 层 多 叉 树 ”的 方式 描述 和 跟踪 每 个 作业 的 运行 状态 ， 作 业 被 抽象 成 三 屋 ， 从 上 往 下 依次 为 : 作业 监控 层 、 任 务 
监控 层 和 任务 执行 情 。 在 作业 监控 层 中 ， 每 个 作业 由 一 个 JobInProgress JIP〉 对 象 描述 和 跟踪 其 整体 运行 状态 以 及 每 个 任务 的 运行 情况 ; 
在 任务 监控 层 中 ， 每 个 任务 由 一 个 TaskInProgress (TIP) 对 象 描述 和 跟踪 其 运行 状态 ;在 任务 执行 层 中 ， 考 虑 到 任务 在 执行 过 程 中 可 能 会 失 
败 ， 因 而 每 个 任务 可 能 尝试 执行 多 次 ， 直 到 成 功 。JobTracker 将 每 次 尝试 运行 一 次 任务 称 为 “任务 运行 尝试 ”而 对 应 的 任务 运行 实例 称 为 
Task Attempt (TA) 。 当 任何 一 个 Task Attempt 运 行 成 功 后 ， 其 上 层 对 应 的 TaskInProgress 会 标注 该 任务 运行 成 功 ， 而 当 所 有 的 TaskInProgress 运 
行 成 功 后 ，JobInProgress 则 会 标注 整个 作业 运行 成 功 。 



























































































































































为 了 方便 查找 和 定位 各 种 对 象 〈 比 如 TaskTracker， 作 业 或 者 任务 等 ) ，JobTracker 将 其 相关 信息 封装 成 各 种 对 象 后 ， 以 key/value 的 形式 
保存 到 数据 结构 Map 中 。 比 如 ， 为 了 能 够 根据 作业 ID 找到 对 应 的 JobInProgress 对 象 ，JobTracker 将 所 有 运行 作业 按照 JobID 与 JopInProgress 的 对 
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应 关系 保存 到 Map [数据 结构 jobs 中 ; 为 了 能 够 查找 每 个 TaskTracker 上 当前 正在 运行 的 Task, JobTracker 将 trackerID 与 Task ID 集合 的 映射 关系 
保存 到 Map 数 据 结构 trackerToTaskMap 中 。JobTracker 的 各 种 操作 ， 比 如 监控 、 更 新 等 ， 实 际 上 就 是 修改 这 些 数据 结构 中 的 映射 关系 。 
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状态 监控 的 一 个 重要 目的 是 实现 容错 功能 。 借 助 监 控 信 息 ，JobTracker 实 现 了 全 方位 的 容错 机 制 ， 包 括 JobTracker、TaskTracker、 
Job/Task、Record 和 磁盘 等 关键 服务 和 对 象 的 容错 。 此 外 ， 通 过 监控 信息 ，JobTracker 可 以 推测 出 ' 拖 后 腿 ” 的 任务 ， 并 通过 启动 备份 任务 加 快 
数据 处 理 速 度 。 















































在 Hadoop MapReduce 中 ，JobTracker 存 在 单 点 故障 问题 ， 当 失效 或 者 重启 后 ， 如 果 已 保存 的 任务 或 者 节点 状态 丢失 ， 则 所 有 正在 运行 的 
作业 将 会 失败 。 为 了 能 够 在 JobTracker 发 生 故 障 时 尽 可 能 大 限度 地 恢复 各 个 作业 ，Hadoop 在 作业 运行 的 各 个 阶段 记录 日 志 ， 以 辅助 作业 恢 
复 。 









































(2) 资源 管理 

















除了 状态 监控 外 ，JobTracker 的 另 一 个 重要 功能 是 资源 管理 。JobTracker 不 断 接 收 各 个 TaskTracker 周 期 性 发 送 过 来 的 资源 量 和 任务 状态 等 
信息 ， 并 综合 考虑 TaskTracker《〈 所 在 DataNode) 的 数据 分 布 、 资 源 剩 余 量 、 作 业 优 先 级 、 作 业 提 交 时 间 等 因素 ， 为 TaskTracker 分 配 最 合适 
的 任务 。 



























































[1 在 JDK 实 现 中 ，Map 数 据 结 构 实际 上 是 红 黑 树 。 





6.2 ”JobTracker 局 动 过 程 分 析 


6.2.1 JobTracker 启 动 过 程 概述 





JobTracker 是 一 个 后 台 进 程 ， 它 包含 一 个 main 函 数 。 我 们 可 以 从 main 函 数 入 手 ， 逐 步 分 析 JobTracker 启 动 过 程 。 在 main 函 数 中 有 
以 下 两 行 启动 JobTracker 的 核心 代码 ; 











JobTracker tracker=startTracker (new JobConf () ) ; // 创 建 JobTracker 对 象 
tracker.offerService(); // 启 动 各 个 服务 























本 小 节 主 要 分 析 这 两 行 代码 的 实现 细节 。 其 中 ， 函 数 startTracker0 的 主要 工作 是 创建 一 个 JobTracker 对 象 ， 其 构造 函数 的 主要 
工作 是 对 一 些 重要 变量 进行 初始 化 ， 而 函数 oferService0 则 是 启动 JobTracker 内 部 一 些 重要 的 服务 或 者 线程 。 



































6.2.2 ”重要 对 象 初始 化 











跟踪 startIrackerO 函 数 内 部 的 执行 过 程 ， 可 定位 到 它 最 终 创 建 了 一 个 JobTracker 对 象 。 该 对 象 对 一 些 重要 对 象 进行 了 初始 化 ， 




















人体 如 表 6-1 所 示 。 





对 象 名 
SecretManager 


aclsManager 


taskScheduler 


对 象 名 


interTrackerServer 


infoServer 


recovery Manager 


JobHistoryServer 


dnsToSwitchMapping 





a 





其 中 ，RPC Server 相 关内 容 已 在 第 4 章 进行 了 介绍 ，JobHistoryServer 和 TaskScheduler 将 分 别 在 6.2.4 节 和 6.7 节 介绍 ， 
点 分 析 ACLsManager、HttpServer 和 DNSToSwitchMapper 三 个 类 。 








表 6-1 JobTracker 需 初 始 化 的 变量 列表 


意义 解释 


DelegationTokenSecretManager MapReduce 安全 管理 相关 的 类 ， 有 具体 参考 第 11 章 


ACLsManager 


作业 级 别 和 队列 级 别 的 管理 和 访问 权限 控制 。 作 业 级 
别 权限 包括 VIEW_ JOB 和 MODIFY _ JOB， 而 队列 级 别 
权限 包括 ADMINISTER_JOBS 和 SUBMIT_JOB 


TaskScheduler 调度 器 对 象 





对 应 类 名 
HttpServer 将 Job, Task 和 TaskTracker 相关 信息 显示 到 Web 前 端 
作业 恢复 管理 ， 即 JobTracker 启动 时 ， 恢 复 上 次 停止 
时 正在 运行 的 作业 ， 并 恢复 各 个 任务 的 运行 状态 
DNSToSwitchMapper 用 于 构造 集群 的 网 络 拓扑 结构 ， 它 能 将 节点 地 址 【〈 卫 
或 者 host) 映射 成 网 络 位 置 





意义 解释 


RecoveryManager 














而 在 本 小 节 





(1) ACLsManager3& 




















它 是 权限 管理 类 ， 提 供 了 checkAccess 方 法 以 对 用 户 的 各 种 操作 进行 权限 检查 。 比 如 ， 用 户 提交 作业 后 ，JobTracker.submitob 函 
数 中 包含 以 下 代码 检查 用 户 是 否 可 以 提交 作业 : 
































try{ 


aclsManager.checkAccess (job, ugi, Operation.SUBMIT JOB) ; 
}catch (IOException ioe) { ~ 
LOG.warn ("Access denied for user"+job.getJobConf () .getUser () 
+". Ignoring job"+jobId, ioe) ; 


job.fail(); 
throw ioe; 


} 





该 类 涉及 两 种 权限 : 队列 权限 和 作业 权限 ， 分 别 由 QueueManager 类 和 JobACLsManager 类 进行 管理 。 


























1) QueueManager 类 : 队列 权限 管理 类 。 在 Hadoop 中 ， 队 列 权限 包括 两 部 分 作业 提交 权限 《哪些 用 户 可 向 队列 中 提交 作业 ) 











和 作业 管理 权限 (哪些 


queue-name 之 .acLadminister-jobs 指 定 ， 






































用 户 可 以 管理 该 队列 中 的 作业 ) ， 分 别 由 参数 mapred.queue. 二 queue-name .acksubmit-job 和 mapred.queue. 一 





























1 体 在 配置 文件 mapred-queue-acls.xml 





WOE 











2) JobACLsManager 类 : 作业 权限 管理 类 。 用 户 提交 作业 时 ， 可 设 定 该 作业 的 查看 权限 和 修改 权限 ， 分 别 由 参数 


mapreduce.job.acLview-job 和 mapreduce.job.acLmodify-job 指 定 。 


作业 查看 权限 主要 




















用 于 限制 访问 作业 相关 的 敏感 信息 ， 





这 些 信息 包括 : 


口 作 业 级 别 的 Counter。 


口 任 务 级 别 的 Counter。 





口 任务 的 诊断 信息 。 
口 TaskTracker 的 web UI 上 显示 的 log 信 息 。 


口 JobTracker 的 web UI 上 显示 的 job.xml 文 件 。 






































口 杀 掉 作业 。 





口 杀 掉 /终止 任务 。 





口 修改 作业 的 优先 级 。 


(2) HttpServer 类 











乍 业 修改 权限 主要 用 于 防止 其 他 用 户 修改 自己 作业 的 信息 ， 这 些 信 息 





包括 : 


Hadoop 对 外 提供 Web 服 务 的 HTIP 服 务 器 ， 它 封装 了 轻 量 级 开源 Web 服 务 器 Jetty |! 。 














(3) DNSToSwitchMapper 接 口 

















该 接口 定义 了 将 DNS 名 称 或 者 节点 四 地 址 转换 成 网 络 位 置 的 规则 。Hadoop 以 层次 树 的 方式 定义 节点 的 网 络 位 置 ， 并 依据 该 位 
置 存 取 数据 或 者 调度 任务 。 比 如 ， 一 个 节点 nodeX 在 数据 中 心 dcX 中 的 机 架 rackX 上 ， 可 以 这 样 表示 它 的 物理 位 











置 : /dcX/rackX/nodeX。 
































默认 情况 下 ，Hadoop 提 供 了 一 个 默认 实现 ScriptBasedMapping， 它 允许 











指定 ) 定义 转换 规则 。 下 面 举 例 说 明 ScriptBasedMapping 的 使 用 方法 。 















































用 户 通过 编写 





























个 脚本 (通过 参数 topology.script.fle.name 


步骤 1 用 户 将 节点 与 网 络 位 置 映射 关系 放 到 目录 ${HADOOP_HOME}/conf 下 的 topology.data 文 件 中 ， 形 式 如 下 : 









































nodel/dcl/rackl 
node2/dcl/rackl 
node3/dcl/rackl 
node4/dc2/rack2 








步骤 2 ”编写 Shel 脚 本 node2rack.sh， 内 容 如 下 : 

















#! /bin/bash 

HADOOP CONF=$ {HADOOP_HOME}/conf 
while[$#-gt 0]; do 

nodeArg=$1 
exec<${HADOOP_CONF}/topology.data 
result="" 

while read line; do 

ar= ($line) 

if["S{ar[0] }"="SnodeArg"]; then 
result="${ar[1]}" 

fi 

done 

shift 

if[-z"Sresult"]; then 
echo-n"/default/rack" 

else 

echo-n"Sresult" 

fi 

done 





步骤 3 在 core-site.xml 中 添加 配置 选项 ， 有 具体 如 下 : 











<property> 
<name>topology.script.file.name</name> 
<value>/opt/scripts/node2rack.sh</value> 
</property> 




















当然 ， 用 户 也 可 以 实现 DNSToSwitchMapper 接 口 ， 

















过 配置 参数 topologynode.switch.mapping.imp] 指 定 对 应 的 实现 类 。 


E 











[1] httpVjetty. codehaus.org/jetty/ 


6.2.3 各 种 线程 功能 


函数 oferServer 会 


(1) expireTrackersThread 线 程 




















该 线程 主要 用 于 发 现 和 清理 死 掉 的 TaskTracker。 每 个 TaskTracker 会 周期 性 
的 汇报 心跳 时 间 。 如 果 某 个 TaskTracker 在 10 分 钊 

















记录 每 个 TaskTracker 最 近 




















启动 JobTracker 内 部 几 个 比较 重要 世 
expireLaunchineTaskThread 和 completedJobsStoreThread。 下 面 分 别 介绍 这 几 个 服务 线程 。 








的 后 台 服 务 线程 ， 分 别 
































是 expireTrackersThread、retireJobsThread、 








E 地 通过 心跳 向 JobTracker 汇 报信 息 ， 而 JobTracker 会 








内 未 汇报 心跳 ， 则 JobTracker 认 为 它 已 死 掉 ， 并 将 它 的 


相关 信息 从 数据 结构 trackerToJobsToCleanup、trackerToTasksToCleanup、trackerToTaskMap、trackerToMarkedTasksMap 中 清除 ， 同 
时 将 正在 运行 的 任务 状态 标注 为 KILLED UNCLEAN。 








(2) retireJobsThread 线 程 























该 线程 主要 




















] 于 清理 长 时 间 驻 留 在 内 存 中 的 已 


























已经 运行 完成 的 作业 信息 。JobTracker 会 将 已 经 运行 完成 的 作业 信息 存放 到 内 存 























中 ， 以 便 外 部 查询 ， 但 随 着 完成 的 作业 越 来 越 多 ， 势 必 会 占用 JobTracker 的 大 量 内 存 ， 为 此 ，JobTracker 通 过 该 线程 清理 驻 留 在 内 
存 中 较 长 时 间 的 已 经 运行 完成 的 作业 信息 。 











当 一 个 作业 满 








足 如 下 条 件 1、 





2 或 者 条 件 1、 














3 时 ， 将 被 从 数据 结构 jobs 转 移 到 过 期 作业 队列 中 。 


























条 件 1 作业 已 经 运行 完成 ， 即 运行 状态 为 SUCCEEDED、FAILED 或 KILLED。 





条 件 2 ”作业 完成 时 间距 现在 


己 经 超过 24 小 时 (可 通过 














条 件 3” 作 汪 拥 

















和 有 者 已 经 完成 作业 总 数 超过 100《〈 可 通 





过 期 作业 被 统一 


会 从 内 存 中 彻底 删 


除 。 


保存 到 过 期 队列 中 。 当 过 


(3) expireLaunchingTaskThread 线 程 

















该 线程 用 于 发 











m 


























现 已 经 被 分 配给 某 个 TaskTracker 但 一 直 未 汇报 信息 的 任务 。 





果 该 任务 在 10 分 钟 内 未 汇报 进度 ， 则 JobTracker 认 为 该 任务 分 配 失败 I, 


(4) completedJobsStoreThread2 fE 





该 线程 将 已 经 运 











& 
: 





行 完 成 的 作业 运行 信息 保存 
































到 HDFS 上 ， } 提供 了 套 存 









































口 用 户 无 法 获 


























取 很 久之 前 的 作业 运行 信息 : 


口 JobTracker 重 启 后 作业 运行 信 














该 线程 通过 保 





存 作业 运行 日 志 的 方式 ， 使 得 用 








默认 情况 下 ， 





用 户 无 法 查询 很 久之 前 某 个 作业 的 运行 信息 。 















































该 线程 不 会 启用 ， 


j 户 可 通过 


前 面 提 到 线程 retireJobsThread 会 

















参数 mapred.jobtracker.retirejob.interva 配 置 ) 。 


过 参数 mapred.jobtracker.completeuserjobs.maximum 配 置 ) 个。 





期 作业 超过 1 000 个 (可 通过 参数 mapred.job.tracker.retiredjobs.cache.size 配 置 ) 时 ， 将 





当 JobTracker 将 某 个 任务 分 配给 TaskTracker 后 ， 如 





并 将 其 状态 标注 为 FAILED。 
































取 这 些 信息 的 API。 该 线程 能 够 解决 以 下 两 个 问 











清除 长 时 间 驻 留 在 内 存 中 的 完成 作业 ， 这 会 导致 
























































户 可 以 查询 任意 时 间 提 交 的 作业 和 还 原作 业 的 运行 信息 





BER: 当 JobTracker 因 故障 重启 后 ， 所 有 原本 保存 到 内 存 中 的 作业 信息 将 会 全 部 丢失 。 




















表 6-2 所 示 的 几 个 参数 配置 # 








启用 该 线程 。 


表 6-2 completedJobsStoreThread 线程 控制 参数 


配置 参数 参数 含义 
mapred.job.tracker.persist.jobstatus.active 是 否 启 用 该 线程 
mapred.job.tracker.persist.jobstatus.hours 作业 运行 信息 保存 时 间 
mapred.job.tracker.persist.jobstatus.dir 作业 运行 信息 保存 路 径 








[1] JobTracker 总 是 假设 TaskTracker 是 不 可 靠 的 ， 它 总 是 认为 TaskTracker 可 能 会 只 接收 新 任务 但 不 启动 它 。 


6.2.4 作业 恢复 














在 MapReduce 中 ，JobTracker 存 在 单 点 故障 问题 。 如 果 它 因 异 常 退 出 后 重启 ， 那 么 所 有 正在 运行 的 作业 运行 时 信息 将 丢失 。 
如 果 不 采 用 适当 的 作业 恢复 机 制 对 作业 信息 进行 恢复 ， 则 所 有 作业 需 重新 提交 ， 且 已 经 计算 完成 的 任务 需 重新 计算 。 这 势必 造成 
资源 浪费 。 
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为 了 解决 JobTracker 面 临 的 单 点 故障 问题 ，Hadoop 设 计 了 作业 恢复 机 制 ， 过 程 如 下 : 作业 从 提交 到 运行 结束 的 整个 过 程 
中 ，JobTiracker 会 为 一 些 关 键 事件 记录 日 志 〈 由 JobHistory 类 完成 ) 。 对 于 作业 而 言 ， 关 键 事件 包括 作业 提交 、 作 业 创建 、 作 业 开 
始 运行 、 作 业 运 行 完成 、 作 业 运 行 失败 、 作 业 被 杀 死 等 ， 对 于 任务 而 言 ， 关 键 事件 包括 任务 创建 、 任 务 开始 运行 、 任 务 运 行 结 
束 、 任 务 运行 失败 、 任 务 被 杀 死 等 。 当 JobTracker 因 故障 重启 后 《重启 过 程 中 ， 所 有 TaskTracker 仍 然 活着 ) ， 如 果 管 理 员 启用 了 
作业 恢复 功能 〈 将 参数 mapred.jobtracker.restartrecover 置 为 tue) ， 则 JobTracker 会 检查 是 否 存在 需要 恢复 运行 状态 的 作业 ， 如 果 
有 ， 则 通过 日 志 恢 复 这 些 作业 的 运行 状态 〈 由 RecoveryManager 类 完成 ) ， 并 重新 调度 那些 未 运行 完成 的 任务 (包括 产生 部 分 结果 
的 任务 ) 。 
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6.3 ”心跳 接收 与 应 答 

心跳 是 沟通 TaskTracker 与 JobTracker 的 桥梁 ， 它 实际 上 是 一 个 RPC 函 数 。TaskTracker 周 期 性 地 调用 该 函数 汇报 节点 和 任务 状态 
信息 ， 从 而 形成 心跳 。 在 Hadoop 中 ， 心 跳 主要 有 三 个 作用 : 

口 判断 TaskTracker 是 否 活 着 。 

口 及 时 让 JobTracker 获 取 各 个 节点 上 的 资源 使 用 情况 和 任务 运行 状态 。 

口 为 TaskTracker 分 配 任务 。 

YER JobTracker'5TaskTrackerz HRH T “pull iii Ae pusik, Bll JobTrackerM 23 Ea [Al TaskTrackerQiS (Ea, Tf 
是 由 TaskTracker 主 动 通过 心跳 "领取 ”属于 自己 的 信息 。JobTracker 只 能 通过 心跳 应 答 的 形式 为 各 个 TaskTracker 分 配 任务 。 

TaskTracker 周 期 性 地 调用 RPC 函 数 heartbeat 向 JobTracker 汇 报信 息 和 领取 任务 。 该 函数 定义 如 下 : 









































public synchronized HeartbeatResponse heartbeat (1 
boolean restarted, 

boolean initialContact, 

boolean acceptNewTasks, 

short responseld) 


[TaskTrackerStatus status, 





该 函数 的 各 个 参数 含义 如 下 。 








OStatus: 该 参数 封装 了 TaskTracker 上 的 各 种 状态 信息 ， 包 括 
String trackerName; //TaskTracker 名 称 ， 形式 如 tracker_mymachine: localhost. 


localdomain/127.0.0.1: 34196 
String host; //TaskTracker 主 机 名 
int httpPort; //TaskTracker 对 外 的 HTT 
int failures; // 该 TaskTracker 上 已 经 失败 的 
List<TaskStatus>taskReports; // 正 在 
volatile long lastSeen; // 上 次 汇报 心 别 
private int maxMapTasks; /*Map slo 
tasktracker.map.tasks.maximumiXie */ 
private int maxReduceTasks; //Reduce slot 总 数 
private TaskTrackerHealthStatus healthStatus; 
private ResourceStatus resStatus; 






































BL 
王 务 运行 状态 


的 时 
tt 总数 ， 即 允许 同时 运行 的 Map Task 总 数 ， 由 参数 mapred. 


//TaskTracker 健 康 状态 
//TaskTracker 资 源 (内 存 ，CPU 等 ) 信息 








口 Restarted: 表示 TaskTracker 是 否 刚刚 重新 启动 。 








A 


DinitialContact: 表示 TaskTracker 是 


DacceptNewTasks: 表示 TaskTracker 是 否 可 以 











用 于 防止 到 





DresponseId: 表示 心跳 响应 编号 ， 


ae 





该 函数 的 返回 


=~ 











接收 新 任务 ， 这 通常 取决 于 
复发 送 心跳 。 每 接收 一 次 心跳 后 ， 该 人 


为 一 个 HeartbeatResponse 对 和 象 ， 该 对 象 主 要 封装 了 JobTracker 向 TaskTracker 下 达 的 命令 ， 


初次 连接 JobTracker。 





Fslot 是 否 有 剩余 和 节点 健康 状况 等 。 








加 1。 























LARUE 











class HeartbeatResponse implements Writable, Conf 


short responseld; // 心 跳 响 应 编号 

int heartbeatInterval; // 下 次 心跳 的 发 送 间 隔 
TaskTrackerAction[]actions; /* 来 自 JobTracker 的 命令 
交 任 务 、 运 行 任务 等 ， 具 体 参 考 6.3.2 节 */ 
Set<JobID>recoveredJobs=new HashSet<JobID> (); 
6.2.4 节 




















/ 


igurable{ 


， 可 能 包括 杀 死 作业 、 杀 死人 
/恢复 完成 的 作业 列表 ， 具 


E 务 、 提 
体 参考 




















Gin 


D 


RJRK 





分 为 两 个 步骤 : 更 新 状态 和 
态 信息 和 外 界 需求 


该 函数 的 内 部 实现 逻辑 
存 到 相应 数据 结构 中 ， 然 后 


























4 


下 达 命 令 。JobTracker 首 先 将 TaskTracker 汇 报 的 最 新 任务 运行 状态 保 


比如 用 户 杀 死 一 个 作业 ) 为 其 下 达 相 应 的 命令 。 








6.3.1 更 新 状态 




















函数 heartbeat 首 先 会 更 新 TaskTracker/Job/Task 的 状态 信息 。 相 关 代 码 如 下 : 








/* 检 查 是 否 允 许 该 TaskTracker 连 接 JobTracker。 当 





一 个 TaskTracker 在 host list (由 参数 mapred.hosts 指 定 ) 中 ， 但 不 在 exclude 
list (由 参数 mapred.hosts .exclude 指 定 ) 中 时 ， 可 接 入 JobTracker*/ 
if (! acceptTaskTracker (status) ) { 


throw new DisallowedTaskTrackerException (status) ; 


























/* 如 果 该 TaskTracker 被 重启 了 ， 则 将 之 标注 为 健康 的 TaskTracker， 并 从 黑 名 单 或 者 灰 名 单 中 清除 (关于 黑 名 单 与 灰 名 单 的 介绍 ， 参 考 6.5. 
节 ) ， 和 否则 ， 启 动 TaskTrackez 容 错 机 制 以 检查 它 是 否 处 于 健康 状态 */ 
if (restarted) { 
faultyTrackers.markTrackerHealthy (status.getHost()) ; 
jelse{ 
faultyTrackers.checkTrackerFaultTimeout (status.getHost(), now) ; 


















































short newResponseld= (short) (responseId+1) ; // 响 应 编号 加 1 
/* 记 录 心 跳 发 送 时 间 ， 以 发 现在 一 定时 间 内 未 发 送 心跳 的 TaskTracker， 并 将 之 标注 为 死亡 的 
TaskTracker， 此 后 不 可 再 向 其 分 配 新 任务 */ 

status.setLastSeen (now) ; 

if (! processHeartbeat (status, initialContact, now) ) {// 处 理 心跳 












































接 下 来 ， 跟 踪 进 入 函数 processHeartbeat 内 部 。 该 函数 首先 进行 一 系列 异常 情况 检查 ， 然 后 调用 以 下 两 个 函数 更 新 
TaskTracker/Job/Task 的 状态 信息 : 




















updateTaskStatuses (trackerStatus) ; // 更 新 Task 状 态 信 息 
updateNodeHealthStatus (trackerStatus, timeStamp) ; // 更 新 节点 健康 状态 








6.3.2 


BIR AS 











更 新 完 状态 信息 后 ，JobTracker 要 


为 TaskTracker 构 造 一 个 HeartbeatResponse 对 象 作为 心跳 应 答 























。 该 对 象 主 要 


达 给 TaskTracker 的 命令 和 下 次 汇报 心跳 的 时 间 间 隔 。 下 面 分 别 对 它们 进行 介绍 。 


LaunchTaskAction (jz 
文 几 


种 。 





对 


A 


1. 下 达 命 令 


JobTracker 将 下 达 





下 面 依次 对 这 











大 给 TaskTracker 的 命令 封装 成 TaskTrackerAction 类 ， 
KilTaskAction( 杀 死 任 


行 新 任务 ) 、 


个 命令 进行 介绍 





(1) RemitTrackerAction 


JobTracker 收 到 TaskTracker 发 送 过 来 的 心跳 
以 恢复 到 一 致 的 状态 。 当 出 现 以 下 


自己 进行 初始 化 ， 


Do 


TaskTracker# 


a 


的 
应 


rf 
中 


运行 同步 标识 和 结束 运行 同步 标识 ， 其 


吉 果 ， 这 种 任务 


到 


任 





口 丢失 上 次 心跳 应 答 信 息 














口 丢 失 TaskTracker 状 态 信 息 





外 保存 起 来 。 如 


= 
IN 











(2) LaunchTaskAction 


RATE T TaskTracker#74) Bic h 














任务 分 成 
TaskType 类 


NK: 





























磁盘 上 的 部 分 结 


中 的 MAP 和 REDUCE 
于 同步 计算 型 任 





计算 型 任 


























WA 
务 和 辅助 型 任 











种 类 
务 或 者 清理 磁盘 上 无 
的 JOB SETUP, JOB CLEANUP 和 TASK _ CLEANUP 三 


型 


3 


ds i 


a 


A 








: JobTracker#24 41) 
个 TaskTracker 非 初次 连接 JobTracker 但 


其 


务 。 
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如 果 
务 ， 任 务 选择 








个 正常 


























(不 在 黑 名 单 中 ) 的 TaskTracker 尚 有 空 
顺序 是 : 先 辅助 型 任 








job-setup task， 有 具体 代码 如 下 : 








i 先 选择 辅助 型 























具体 特 











务 , 再 






































村 点 


计算 型 人 有 





List<Task>tas 

// 如 果 没 有 辅助 型 则 选择 计算 型 任务 
if (tasks==null) 

// 由 任务 调度 器 选择 一 个 或 多 个 计算 理 任 务 
七 aS 





if (tasks! =nul 
for (Task task: 





1) { 
tasks) { 


息 后 ， 














务 ) 、 





3 








不 包括 ReinitTrackerAction ( Œ} 





新 初始 化 ) 、 





A 
AY 


KK 如 obAction( 杀 死 作 业 ) 和 CommitTaskAction 〈 提 交 任 务 ) 五 





首先 要 进行 一 致 性 

















种 不 一 


E 何 一 个 心跳 信 


致 情况 时 ，JobTracker 会 


: JobTracker 会 保存 向 每 个 TaskTracker 发 送 的 最 近 
非 初 次 连接 JobTracker (initialContact! =true) ， 而 最 近 的 心跳 应 答 信 息 丢 失 了 ， 则 这 





检查 ， 如 果 发 现 异常 情况 ， 则 会 要 求 TaskTracker 重 新 








向 TaskTracker 下 达 ReinitTrackerAction 命 




















Hn 


4 





心跳 应 答 信 息 ， 如 果 JobTracker 未 刚刚 


文 是 一 种 不 一 致 状态 。 
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会 将 TaskTracker 状 态 〈 封 装 在 类 TaskTrackerStatus 中 ) 
































ype 
4 大 态 信 sy 


却 不 存在 ， 则 也 是 一 种 不 一 致 状态 。 








种 类 


已 在 第 4 章 进 行 
JobTracker 负 责 调度 ， 且 运行 优先 级 高 





expireLaunchingTasks.addNewTask (task.getTaskID()) ; 


// 将 分 配 的 任 
actions.add (n 
} 
} 





务 封装 成 LaunchT 





ew LaunchT 


(3) KillTaskAction 


askAction 对 象 
askAction (task) ) ; 


Es. mtd 


E 务 。TaskTracker 接 收 到 该 命 
中 ， 计 算 型 任务 

专门 的 任务 调度 器 对 
的 目录 ， 包 括 job-setup task 


了 介 








令 后 
是 处 理 








闲 Slot (acceptNewTasks 为 ttue〉， 则 JobTracker 会 为 该 TaskTracker 分 配 间 





FH 








助 型 任务 





会 启动 一 个 子 进程 运 


它们 进行 调度 ; 而 加 
、job-cleanup task#iltask-cleanup task 三 种 (对 应 TaskType 类 
型 ) ， 其 中 ，job-setup task 和 job-cleanup task 分 别 用 作 计 算 型 
绍 ， 而 task-cleanup task 则 用 于 清理 失败 的 计算 型 


于 计算 型 任务 。 


行 该 任务 。Hadoop 将 一 个 作 ， 
， 包 括 Map Task 和 Reduce Task 两 种 (对 
助 型 任务 则 不 会 处 理 实际 的 数据 ， 通 




















实际 数据 的 任务 





















































! 任 务 开始 
MES CAS 


























7 
， 选 择 顺序 依次 为 job-cleanup task, task-cleanup task 和 








任务 ， 选 择优 先 级 从 高 到 低 依次 为 : job-cleanup task, task-cleanup 上 task 和 
， 这 样 可 以 让 运行 完成 的 作业 快速 结束 ， 新 提交 的 作业 立刻 进入 运行 状态 */ 
ks=getSetupAndCleanupTasks (taskTrackerStatus) ; 


ks=taskScheduler.assignTasks (taskTrackers.get (trackerName) ) ; 














该 类 封装 了 TaskTracker 需 杀 死 的 任务 。TaskTracker 收 到 该 命令 后 会 杀 掉 对 应 任务 、 清 理工 作 目 录 和 释放 slot。 导 致 JobTracker 
向 TaskTracker 发 送 该 命令 的 原因 有 很 多 ， 主 要 包括 以 下 几 个 场景 : 



































Lou 



































口 用 户 使 用 命令 "binhadoop job-kil- task’ EK “bin/hadoop job-fiLtaslke 亲 死 一 个 任务 或 者 使 一 个 任务 失败 。 
























































口 启用 推测 执行 机 制 后 ， 同 一 份 数据 可 能 同时 由 两 个 Task Attempt 处 理 。 当 其 中 一 个 Task Attempt 执 行 成 功 后 ， 另 外 一 个 处 理 
相同 数据 的 Task Attempt 将 被 杀 掉 。 












































口 某 个 作业 运行 失败 ， 它 的 所 有 任务 将 被 杀 掉 。 











D 口 TaskTracker 在 一 定时 间 内 未 汇报 心跳 ， 则 JobTracker 认 为 其 死 掉 ， 它 上 面 的 所 有 Task 鬼 被 标注 为 死亡 。 

















(4) KilJobAction 












































该 类 封装 了 TaskTracker 待 清理 的 作业 。TaskTracker 接 收 到 该 命令 后 ， 会 清理 作业 的 临时 目录 。 导 致 JobTracker 向 TaskTracker 发 
送 该 命令 的 原因 有 很 多 ， 主 要 包括 以 下 几 个 场景 : 















































口 用 户 使 用 命令 "binhadoop job-kif 或 者 "binhadoop job- 和 ip 亲 死 一 个 作业 或 者 使 一 个 作业 失败 。 




















口 作业 运行 完成 ， 通 知 TaskTracker 清 理 该 作业 的 工 











EE 


EHR. 
































口 作 业 运 行 失 败 ， 即 同一 个 作业 失败 的 Task 数 目 超过 一 定 比例 。 


(5) CommitTaskAction 





该 类 封装 了 TaskTracker 需 提交 的 任务 。 为 了 防止 同一 个 TaskInProgress 的 两 个 同时 运行 的 Task Attempt〈 比 如 打开 推测 执行 功 
能 ， 一 个 任务 可 能 存在 备份 任务 〉 同 时 打开 一 个 文件 或 者 往 一 个 文件 中 写 数据 而 产生 冲突 ，Hadoop 让 每 个 Task Attempt 写 到 单独 
一 个 文件 (以 TaskAttemptID 命 名 ， 比 如 attempt_201208071706_0008 r 000000 0) 中。 通常 而 言 ，Hadoop 让 每 个 Task Attempt 将 计 
算 结果 写 到 临时 目录 $ {mapred.output.dir}/_temporary/ $f{taskid} 中 ， 当 某 个 Task Attempt 成 功 运行 完成 后 ， 再 将 运算 结果 转移 到 最 终 
目录 $ {mapred.output.dir} 中 。Hadoop 将 一 个 成 功 运行 完成 的 Task Attempt 结 果 文件 从 临时 目录 “提升 "至 最 终 目录 的 过 程 ， 称 为 “任务 
提交 ”。 当 TaskInProgress 中 一 个 任务 被 提交 后 ， 其 他 任务 将 被 杀 死 ， 同 时 意味 着 该 TaskInProgress 运 行 完成 。 
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2. 调 整 心跳 间隔 











TaskTracker 心 跳 时 间 间 隔 大 小 应 该 适度 ， 如 果 太 小 ， 则 JobTracker 需 要 处 理 高 并 发 的 心跳 连接 请 求 ， 必 然 产 生 不 小 的 并 发 压 
力 ; 如 果 太 大 ， 空 闲 的 资源 不 能 及 时 汇报 给 JobTracker〈 进 而 为 之 分 配 新 的 Task) ， 造 成 资源 空间 ， 进 而 降低 系统 吞吐 率 。 
























































TaskTracker 汇 报 心跳 的 时 间 间 隔 并 不 是 一 成 不 变 的 ， 它 会 随 着 集群 规模 的 动态 调整 〈 比 如 节点 死 掉 或 者 用 户 动 态 添加 新 节 
点 ) 而 变化 ， 以 便 能 够 合理 利用 JobTracker 的 并 发 处 理 能 力 。 在 Hadoop MapReduce 中 ， 只 有 JobTracker 知 道 某 一 时 刻 集 群 的 规模 ， 
丸 此 由 JobTracker 为 每 个 TaskTracker 计 算 下 一 次 汇报 心跳 的 时 间 间 隔 ， 并 通过 心跳 机 制 告诉 TaskTracker。 


















































































































































JobTracker 人 允许 用 户 通过 参数 配置 心跳 的 时 间 间 隔 加 速 比 ， 即 每 增加 mapred.heartbeats.in.second (默认 是 100， 最 小 是 1) 个 节 

















点 ， 心 跳 时间 间 隔 增 加 mapreduce.jobtracker.heartbeats.scaling,factor (默认 是 1， 最 小 是 0.01) 秒 。 同 时 ， 为 了 防止 用 户 参 数 设置 不 合 


A 

















理 而 对 JobTracker 产 生 较 大 负载 ，JobTracker 要 求 心跳 时 间 间 隔 至 少 为 3 秒 山 。 具 体 计算 方法 如 下 : 








public int getNextHeartbeatInterval () { 
/ /获取 当前 TaskTracker 总 数 ， 即 集群 当前 规模 
int clusterSize=getClusterStatus() .getTaskTrackers (); 
// 计 算 新 的 心跳 间隔 
int heartbeatInterval=Math.max ( 
Cint) (1000 * HEARTBEATS SCALING FACTORr 
Math.ceil ( (double) clusterSize/ 








NUM_HEARTBEATS IN SECOND) ) ， 
HEARTBEAT INTERVAL MIN) i 
return heartbeatInterval; 

} 








[1] 考虑 在 中 小 规模 集群 下 ， 心 跳 时 间 间 隔 至 少 为 3 秒 ， 这 会 降低 系统 吞吐 率 ， 在 最 新 版 本 
































https://issues.apache. org/jira/browse/MAPREDUCE- 1906. 





Ph， 已 经 调整 为 300 毫 秒 ， 














6.4 Job 和 Task 运 行 时 信息 维护 


JobTracker 最 重要 的 功能 之 一 是 状态 监控 ， 包 括 TaskTracker、Job 和 Task 等 运行 时 状态 的 监控 ， 其 中 ，TaskTracker 状 态 监控 比较 简单 ， 
只 要 记录 其 最 近 心 跳 汇报 时 间 和 健康 状况 (由 TaskTracker 端 的 监控 脚本 检测 ， 并 通过 心跳 将 结果 发 送 给 JobTracker) 即 可 。 本 节 重 点 分 析 
Job 和 Task 的 监控 方法 ， 内 容 涉 及 作业 描述 模型 、 人 作业/ 任务 运行 时 监控 信息 、 人 作业/ 任务 状态 转换 等 。 










































































6.4.1 作业 描述 模型 

















如 图 6-2 所 示 ，JobTracker 在 其 内 部 以 ' 王 层 多 又 树 ? 的 方式 描述 和 跟踪 每 个 作业 的 运行 状态 。JobTracker 为 每 个 作业 创建 一 个 
JobInProgress 对 象 以 跟踪 和 监控 其 运行 状态 。 该 对 象 存在 于 作业 的 整个 运行 过 程 中 : 它 在 作业 提交 时 创建 ， 作 业 运 行 完 成 时 销毁 。 同 时 ， 
为 了 采用 分 而 治之 的 策略 解决 问题 ，JobTracker 会 将 每 个 作业 拆 分 成 若干 个 任务 ， 并 为 每 个 任务 创建 一 个 TaskInProgress 对 象 以 跟踪 和 监控 
其 运行 状态 ， 而 任务 在 运行 过 程 中 ， 可 能 会 因为 软件 Bug、 硬 件 故障 等 原因 运行 失败 ， 此 时 JobTracker 会 按照 一 定 的 策略 重新 运行 该 任 
务 ， 也 就 是 说 ， 每 个 任务 可 能 会 尝试 运行 多 次 ， 直 到 运行 成 功 或 者 因 超过 尝试 次 数 而 失败 。JobTracker 将 每 运行 一 次 任务 称 为 一 次 “任务 
运行 尝试 ” 即 Task Attempt。 对 于 某 个 任务 ， 只 要 有 一 个 Task Attenmpt 运 行 成 功 ， 则 相应 的 TaskInProgress 对 象 会 标注 该 任务 运行 成 功 ， 而 
当 所 有 的 TaskInProgress 均 标注 其 对 应 的 任务 运行 成 功 后 ，JobInProgress 对 象 会 标识 整个 作业 运行 成 功 。 


JobInProgress 


TaskInProgress 
Task Attempt Task Attempt 


图 6-2 三 层 多 叉 树 ”作业 描述 方式 

















































































































TaskInProgress TaskInProgress 
Task Attempt Task Attempt 


如 图 6-3 所 示 ， 为 了 区 分 各 个 作业 ，JobTracker 会 赋予 每 个 作业 一 个 唯一 的 ID。 该 ID 由 三 部 分 组 成 : 作业 前 绥 字 符 串 、JobTracker 启 动 
时 间 和 作业 提交 顺序 ， 各 部 分 通过 “ "连接 起 来 组 成 一 个 完整 的 作业 ID， 比 如 job_ 201208071706 0009， 对 应 的 三 部 分 分 别 是 job”、 
“201208071706"” 和 "009”(JobTracker 运 行 以 来 第 9 个 作业 ) 。 每 个 任务 的 ID 继承 了 作业 的 ID， 并 在 此 基础 上 进行 了 扩展 ， 它 由 三 部 分 组 
成 : 作业 ID (其 中 前 级 字符 串 变 为 “task”) 、 任 务 类 型 (map 还 是 reduce) 和 任务 编号 〈 从 000000 开 始 ， 一 直到 999999) 。 比 
如 ，task 201208071706 0009 m 000000， 表 示 它 的 作业 ID 为 task 201208071706 0009， 任 务 类 型 为 map， 任 务 编号 为 000000。 每 个 Task 
Attempt 的 ID 继承 了 任务 的 ID， 它 由 两 部 分 组 成 : 任务 ID《〈 其 中 前 缀 字符 串 变 为 "attempf”” 和 运行 尝试 次 数 〈 从 0 开始 ) ， 比 
如 ，attempt 201208071706 0009 m 000000 0 表示 任务 task 201208071706 0009 m 000000 的 第 0 次 尝试 。 
















































































VY 






















































































TaskID 
(task_201208071706 __0009_m_000001) 





TaskAttemptID TaskAttemptID 


(attempt_201208071706 _0009_m_000000_0)} | (attempt_201208071706 _0009_m_000000_1) TaskAttemptID 


图 6-3 Job/TaswTaskAttempt 的 ID 继承 关系 


6.4.2 JobInProgress 


JobInProgress 类 主 











而 其 调度 函数 相关 实现 将 在 6.7 节 中 介绍 。 


JobInProgress 维 











信息 随 着 作业 的 运行 


C1) 作业 静态 信 ， 


作业 静态 信息 是 指 


n 


护 了 两 种 作业 信息 : 
而 动态 变化 。 








是 静态 信息 4 


Gy 


这 些 信息 


要 用 于 监控 和 跟踪 作业 运行 状态 ， 并 为 调度 器 提供 最 底层 的 调度 接口 。 本 小 节 主要 介 








是 作业 提交 之 时 就 

















作业 提交 之 时 就 已 经 古 









































定好 的 属性 信息 ， 主 要 包括 以 下 儿 项 : 











绍 其 作业 监控 信息 ， 





这 些 








己 经 确定 好 的 ， 另 一 种 是 动态 信息 ， 





//map task, 
TaskIn 
TaskIn 
TaskIn 
TaskInProgress setup[] 


reduce task, 
Progress maps[] 
Progress reduces [] 
Progress cleanup[] 


cleanup task 和 setup task 对 应 的 TaskInProgress 


=new TaskInProgress[0]; 
=new TaskInProgress[ 
=new TaskInProgress[ 
=new TaskInProgress[0]; 


int numMapTasks=0; //Map Task 个 数 
int numReduceTasks=0; //Reduce Task 个 数 


fina 
fina 
vol 


vola 


设置 。 





atil 


L 
1 


long memoryPerMap; 
long memoryPerRedu 
le int numSlots 
e int numSlots 





til 








器 便 不 


fina 


//* 


int 





// 人 允许 的 Map Task Wr tef 


// 人 允许 的 Reduce Task 失 败 























为 该 节点 分 配 该 作业 


l int maxTaskFailure 





Task 完 成 后 ， 





5% 的 Map 
completedMaps 








| int mapFailuresPer 











L int reduceFailures 


PerMap=1; // 每 个 Map 
PerReduce=1; // 每 个 Redu 
/* 人 允许 每 个 TaskTracker 上 失败 的 Task 个 数 ， 
Ss lee Sag rane ee 


A ay 
ForReduceSlowstart=0; //4/bMap 


// 每 个 Map Task 需 要 的 
ce; // 每 个 Reduce Tas 
Tas 





0]; 
0]; 


内 存量 
k 需 要 的 内 存量 

k 需 要 的 slot 个 数 

ce Task 需 要 的 slot 个 数 




















该 值 
务 *y 


sPerTracker; 


LT COMPLETED MAPS 











PERC] 





ENT 





FOR REDUCE 











以 调度 Reduce Task 


cent; 


Percent; 





Task 完 成 后 


JobPriority priority=JobPriority.NORMAL; // 作 业 优 先 级 








开始 调 


上 限 ， 通 过 参数 mapredq.max.map .failures.percent 设 置 


SLOWSTART= 


默认 是 4， 通 过 参数 mapred.max.tracker.failures 
时 ， 会 将 该 节点 添加 到 该 作业 的 黑 名 单 中 


， 调 度 


0.05£; 


f¥Reduce Task 


比例 上 限 ， 通 过 参数 mapredq.max.requce.failures.percent 设 置 





(2 


作业 动态 信息 是 
了 任务 调度 


a 


) 作业 动态 信 ， 





作业 运 
提供 决策 依据 。 


\ 是 指 




































































行 过 程 中 会 动态 更 新 的 信息 。 这 些 信息 对 于 发 现 TaskTracker/Job/Task 故 障 非 常 有 用 ， 


也 可 以 为 调度 





// 节 


会 产 4 
int failedReduceTIPs=0; // 失 
private volatile boolean launchedCleanup=false; // 是 否 
private volatile boolean launchedSetup=false; (ao 
private volatile boolean jobKilled=false; // 作 业 是 
private volatile boolean jobFailed=false; // 作 业 是 


askInProgress 的 映射 关系 ， 即 Tas KInProdtess 输 入 数据 





runningMapTasks=0; / 


runningReduceTasks=0; 


finishedMapTasks=0; 


finishedReduceTasks= 


失败 的 Ma 


failedMapTasks=0; // 
failedReduceTasks=0; 


speculativeMapTasks= 
speculativeReduceTasks=0; 

















/正在 运行 的 Map Task% H 
// 正 在 运行 的 Reduce T 
// 运 行 完 成 的 Map Task 数 
0; // 运 行 完 成 的 Reduce 























// 失 败 


0; // 正 在 运行 的 备份 任务 
// 正 在 运行 的 备份 任 




















ask 数 





























Task 数 目 
ap Task Attempt 数 目 
的 Reduce Task Attempt 数 晶 


P) 数 
务 (REDUCE 

















(MA 



























































failedMapTIPs=0; /* 失 败 的 TaskInProgress ( 





E 最 终结 果 */ 


点 与 T 











IAP) 数 









































败 的 TaskInProgress (REDU 





CE) 数目 


| 








ae 


Map<Node, List<Tas kInProgress>>nonRunningMapCache; 





// 节 





点 及 其 上 面 正在 运行 














// 按 | 


final 


//Ki 








Nici 








List<TaskInProgre 








HE FEI BSGBEAT A 
SortedSet<TaskInP 
运行 的 Map Task 和 集合 





入 Task 映 射 关 系 
Set<TaskInProgress> > runningMapCache; 
居 本 地 性 的 Map Task， 如 果 一 个 Map Task 的 InputSpl 
SIENA EE AIRE 


final 


ss>nonLocalMaps; 


序 的 TIP 集 合 


rogress>failedMaps; 





Set<TaskInProgress>nonl 


// 未 i 
Set<T 


//1E 











运行 的 Reduce Task 集 合 








Set<T 


// 待 





LocalRunningMaps; 


askInProgress>nonRunningReduces; 
在 运行 的 Reduce Task 和 集合 
oo eee ee 























清理 的 Map Tas 


k 列 表 ， 比 如 





























接 通过 命令 \pin/haqdoop 








己 启 动 CLleanup Task 


1 启动 Setup Task 
BORA 
CAM 


ES ARTI 





it Location 


job-kil1” 杀 死 的 Task 


空 ， 则 进行 任 





者 对 应 的 输入 数据 将 被 丢弃 ， 





List<TaskAttemptID>mapCleanupTasks=new LinkedList<TaskAttemptID> (); 
List<TaskAttemptID>reduceCleanupTasks=new LinkedList<TaskAttemptID> (); 
long startTime; // 作 业 提交 时 间 

long launchTime; // 作 业 开始 执行 时 间 

long finishTime; // 作 业 完 成 时 间 























6.4.3 TaskInProgress 


TasklnProgress 类 维 
存在 多 个 Task Attempt, H. 





可 能 





同一 时 刻 ， 可 

















和 跟踪 ， 只 要 但 


个 任 





E 何 








护 了 一 个 Task 运 行 过 程 


务 尝 试 运行 成 功 ，TaskInProgress 就 会 标注 该 人 








的 全 部 信息 。 在 Hadoop 中 ， 由 于 一 个 全 


E 务 可 能 会 推测 执行 或 者 重 























多 个 处 理 相同 的 任 














务 尝试 同时 在 执行 ， 
E 务 执行 





而 这 些 任 





成 功 。 


插 务 被 同一 个 TaskInProgress 对 象 管理 


新 执行 ， 所 以 会 
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private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 
private 


// 该 TaskInProgress 的 下 
int nextT 


final TaskSplitMetaInfo splitiInfo; //Tas 


int numMaps; //Map Task 数 目 ， 





int partition; // 该 Task 在 task 列 表 中 的 索引 
JobTracker jobtracker; //JobTrac 





k 要 处 
Reduce Task 有 











只 对 























ker 对 象 ， 





于 获取 全 











TaskID id; //task ID， 其 后 

















的 JobI 






































final int numSlotsRequired; // 运 行 该 Task 需 要 的 slot 数 上 
int successEventNumber=-1; 

int numTaskFailures=0; //Task Attempt 失 败 次 数 

int numKilledTasks=0; //Task Attempt 被 杀 死 次 数 
double progress=0; // 任 务 运行 进度 

String state=""; // 运 行 状 态 

long startTime=0; //TaskInprogress 对 象 创建 时 间 


long execStartTime=0; // 第 一 个 Task Attempt 开 始 运行 
long execFinishTime=0; // 最 后 一 个 运行 成 功 的 




















时 间 





里 的 Split 信 息 


cke: 局 时 钟 
ji 加 下 标 构成 Task Attempt ID 


JobInProgress job; // 该 TaskInProgress 所 在 nProgress 


Task Attempt 完 成 时 间 




















int completes=0; //Task Attempt 运 行 完成 数目 ,实际 只 有 两 个 值 ，0 和 1 
boolean failed=false; // 该 TaskInProgress 是 否 运行 失败 
boolean killed=false; // 该 TaskInProgress 是 否 被 杀 死 


boolean jobCleanup=false; 


// 该 TaskInProgress 是 否 为 cleanup Task 


boolean jobSetup=false; //i%TaskInProgress#fASetup Task 

















个 可 








askId=0; 


Task Attempt ID 


// 使 得 该 TaskInProgress 运 行 成 功 的 那个 Task ID 


private 
// 第 一 


eee 





// 正 在 运行 的 Task ID 与 TaskTrac 





private 


//i%TaskInProgress 


private 


//Task ID 与 TaskSta 


private 


new TreeMap<T 
//Cleanup Task ID 与 TaskT 


private 


new TreeMap<T 


// 所 有 已 经 运行 失败 的 





private 


// 某 个 Task Attempt 运 行 成 功 后 ， 


private 





// 待 杀 死 的 Task 列 表 


private 








ID 
TaskAttemptID firstTaskId; 


ps 


reeMap<TaskAttempt 
已 运行 的 所 有 
TreeSet<TaskAttemp 
tus 映 射 关系 
ap<TaskAttemp 
askAttemptID, 
rac 


empt 
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[Tree 
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reeMap<TaskAt 
askAttemp 
Tas 


TreeSet<S 











EH 点 列表 





TaskAttemptID successfulTaskId; 
个 运行 的 Task Attempt) 


ker ID 之 间 的 映射 关系 
ID, String>activeTasks=new TreeMap<TaskAttemptID, 


String> (); 





tID>tasks=new TreeSet<TaskAttemp 


tID, TaskStatus>taskStatuses= 
TaskStatus> (); 

ker ID 映射 关系 

ID, String>cleanupTasks= 

ID, String> (); 

















TreeSet<TaskAt 

















TreeMap<TaskAt 


Boolean> (); 


// 等 待 被 提 


private 





TaskAttemptID taskToCommit; 


Fh ir IE A 








TaskAttempt ID， 包 括 已 经 运行 完成 的 和 正在 运行 的 








tID> () ; 


tring>machinesWhereFailed=new TreeSet<String> (); 
E 运 行 的 Task Attempt 保 存在 该 集合 中 
temptID>tasksReportedClosed=new TreeSet<TaskAttemptID> (); 








ttemptID, Boolean>tasksToKill=new TreeMap<TaskAttemptID, 


交 的 Task Attempt, 该 Task Attempt 最 终 使 得 TaskInProgress 运 行 成 功 





6.4.4 ”作业 和 任务 状态 转换 图 





在 Hadoop MapReduce 中 ， 作 业 和 任务 是 有 生命 周期 的 ， 它 们 的 状态 受 各 种 行为 的 影响 而 发 生变 化 。 在 本 小 节 中 ， 我 们 将 分 
析 作 业 和 任务 涉及 的 状态 转移 以 及 导致 状态 转移 的 事件 。 














(1) 作业 状态 转换 图 

















前 面 提 到 ， 作 业 的 运行 时 信息 由 JobInProgress 类 进行 监控 和 维护 ， 因 此 ， 作 业 状 态 转移 也 由 该 类 进行 更 新 。 在 Hadoop 中 ， 一 
个 作业 在 运行 过 程 中 可 能 涉及 所 有 可 能 的 状态 转移 ， 如 图 6-4 所 示 。 


PREP 
RUNNING 
FAILED 


SUCCEEDED 










































KILLED 









Ds 








6-4 作业 状态 转换 图 











图 6-4 中 涉及 的 状态 转换 以 及 对 应 事件 如 下 。 





OPREP—RUNNING: 作业 的 Setup Task (job-setup Task) 成 功 执行 完成 。 


ORUNNING—SUCCEEDED:{f JV ff] Cleanup Task (job-cleanup Task) 执行 成 功 。 





Q PREP—FAILED/KILLED: \ J4 H Shells +A SE (EL, EB bin/hadoop job[-kill-fail]<jobid> 。 




















DRUNNING 一 FAILED: 多 种 情况 可 导致 该 状态 转移 ， 包 括 人 为 使 用 Shel 命 令 杀 死 作业 (使 用 “bin/hadoop job-fail< jobid> "ir 
令 ) ， 作 业 的 Cleanup/Setup Task 运 行 失败 和 作业 失败 的 任务 数 超过 了 一 定 比 例 。 











DRUNNING 一 KILLED: 人 为 使 用 Shel 命 令 杀 死 作 业 ， 比 如 使 用 “bim/hadoop job-kill<jobid> sit +. 








(2) 任务 状态 转换 图 




















在 Hadoop 中 ， 一 个 任务 的 状态 变化 可 能 发 生 在 JobTracker 端 或 者 TaskTracker 端 。 总 结 起 来 ， 一 个 任务 在 运行 过 程 中 可 能 涉及 
所 有 可 能 的 状态 转移 ， 如 图 6-5 所 示 。 














UNASSIGNED 
FAILED UNCLEAN "i RUNNING 


FAILED aoe: 
SUCCEEDED 


王 务 状态 转换 图 





























图 6-5 中 涉及 的 状态 转换 以 及 对 应 事件 如 下 。 








QUNASSIGNED—>RUNNING: 任务 初始 化 状态 为 UNASSIGNED， 当 JobTracker 将 作 
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ILLED UNCLEAN 




















TaskTracker 会 为 它 准备 运行 环境 并 启动 它 ， 之 后 该 任务 进入 RUNNING 状 态 。 








QRUNNING--COMMIT PENDING: 该 状态 转换 存在 于 产 9 
Task) 中 ， 当 任务 处 理 


AMA 
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完 最 后 





U RUNN 
Map Task 人 处 ] 





























E 完 最 后 一 条 记录 后 便 意 味 着 任务 运行 成 功 。 








DRUNNING/COMMIT PENDING—KILLED UNCLEAN: TaskTrackerKE 











ING 一 SUCCEEDED: 该 状态 转换 只 存在 于 Map Task〈 且 这 些 Map Task 的 结果 将 被 Reduce Task 进 一 步 处 型 


FE 务 分 配给 某 个 TaskTracker 后 ， 该 





ES (Reduce Task 或 者 map-only 类 型 作业 |! 的 Map 
条 记录 后 进入 COMMIT PENDING 状 态 ， 以 等 待 JobTracker 批 准 其 提交 最 后 结果 。 











M2 


=] 











E) 中 ， 


上 来 自 JobTracker 的 KilTaskAction 命 令 后 ， 会 将 对 应 














任务 由 RUNNING/COMMIT_ PENDING 状 态 转化 为 KILLED UNCLEAN 状 态 ， 

















通常 产生 的 场景 是 人 为 杀 死 但 





E 务 ， 同 一 个 TIP 的 多 个 











同时 运行 的 Task Attempt 中 有 一 个 成 功 运行 完成 而 杀 死 其 
KILLED UNCLEAN 等 。 





他 Task Attempt, TaskTracker 医 














超时 导致 其 上 所 有 任务 状态 变 为 








ORUNNING/COMMIT PENDING->FAILED UNCLEAN: 多 种 情况 下 会 导致 该 状态 
Baik. A 








OUNASSIGNED—>FAILED/KILLED: A SE 1 





EX 





UO KILLED UNCLEAN/FAILED UNCLEAN->FAILED/KILLED:— H44 
接 下 来 必然 进入 FAILEDKILLED 状 态 ， 以 清理 




















已 经 写 入 HDFS J 











上 的 部 分 结果 。 











m] 
Li 


QO SUCCEEDED>KILLED:—~ ATP E H “Task Attempt TER, me A 


为 杀 死 某 个 Task， 而 TaskTracker 刚 好 汇报 对 应 Task 执 行 成 功 。 


E 务 也 














BL i 


端 远 





A SUCCEEDED/COMMIT_PENDING—>FAILED:Reduce Task 从 Map Task. 





务 在 一 定时 间 内 未 汇报 进度 〈 从 而 被 TaskJracker 杀 掉 ) 、 内 存 使 用 量 超过 期 望 值 或 者 其 他 运行 过 程 


[ 报 成 功 ， 则 备份 人 


程 读 取 数 和 


转移 ， 包 括 本 地 文件 读 写 错误 、Shuffle 阶 
Pp 出 现 的 错误 。 





FE 务 进入 KILLED UNCLEAN/FAILED UNCLEAN 状 态 ， 

















E 务 将 被 杀 掉 或 者 





IFA 

















届时 ， 发现 数 据 损坏 或 者 丢失 ， 则 将 对 





应 Map Task 状 态 标注 为 FAILED 以 便 重 新 得 到 调度 。 






































[1] Map-only 类 型 作业 是 指 只 有 IMap Task 而 没有 Reduce Task 的 作业 。 对 于 这 种 作业 ，Map Task 直 接 将 结果 写 到 HDFS 上 。 


6.5 ”容错 机 制 


6.5.1 JobTracker 容 错 








在 MapReduce 中 ，JobTracker 掌 握 着 整个 集群 的 运行 时 信息 ， 包 括 节点 健康 状况 、 资 源 分 布 情况 以 及 所 有 作业 的 运行 时 信息 
等 。 如 果 JobTracker 因 故障 而 重启 ， 部 分 信息 很 容易 通过 心跳 机 制 重新 构造 ， 比 如 节点 健康 情况 和 资源 分 布 情况 ， 但 对 于 作业 的 
运行 时 信息 而 言 ， 可 能 将 会 全 部 丢失 ， 这 使 得 用 户 不 得 不 重新 提交 未 运行 完成 的 作业 ， 这 意味 着 之 前 已 经 运行 完成 的 任务 不 得 不 
运行 ， 进 而 造成 资源 浪费 。 从 以 上 分 析 可 看 出 ，JobTracker 容 错 的 关键 技术 点 是 如 何 保存 和 恢复 作业 的 运行 时 信息 。 
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从 作业 恢复 粒度 角度 看 ， 当 前 存在 三 种 不 同 级 别 的 恢复 机 制 ， 级 别 由 低 到 高 依次 是 作业 级 别 、 任 务 级 别 和 记录 级 别 ， 其 中 ， 























级 别 越 低 ， 实 现 越 简 单 ， 但 造成 的 资源 浪费 越 严 重 。 在 1.0.0 以 及 之 前 版 本 中 ，Hadoop 采 用 了 任务 级 别 的 恢复 机 制 趾 ， 即 以 任务 
为 基本 单位 进行 恢复 ， 这 种 机 制 是 基于 事务 型 日 志 完 成 作业 恢复 的 ， 它 只 关注 两 种 任务 : 运行 完成 的 任务 和 未 运行 完成 的 任务 。 
作业 执行 过 程 中 ，JobTracker 会 以 日 志 的 形式 将 作业 以 及 任务 状态 记录 下 来 ， 一 旦 JobTracker 重 启 ， 则 可 从 日 志 中 恢复 作业 的 运行 
状态 ， 其 中 已 经 运行 完成 的 任务 无 须 再 运行 ， 而 未 开始 运行 或 者 运行 中 的 任务 需 重新 运行 。 这 种 方案 实现 比较 复杂 ， 需 要 处 理 的 
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特殊 情况 比较 多 ， 为 了 简化 设计 ， 从 0.21.0 版 本 开始 ，Hadoop 采 用 了 作业 级 别 的 恢复 机 制 中。 该 机 制 不 再 关注 各 个 任务 的 运行 状 
态 ， 而 是 以 作业 为 单位 进行 恢复 ， 它 只 关注 两 种 作业 状态 : 运行 完成 或 者 未 运行 完成 。 当 JobTracker 重 启 后 ， 凡 是 未 运行 完成 的 
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作业 将 自动 被 重新 提交 到 Hadoop 中 重新 运行 。 除 了 这 两 种 方案 ， 学 术 界 还 尝试 着 研究 记录 级 别 的 恢复 机 制 中] 。 该 机 制 尝试 着 从 
失败 作业 的 第 一 条 尚未 处 理 的 记录 《〈 断 点 ) 开始 恢复 一 个 任务 ， 以 尽 可 能 地 减少 任务 重新 计算 的 代价 。 
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[1] https//Assues. apache.org/jira/browse/HADOOP-3245 

[2] https//Assues. apache. org/jira/browse/MAPREDUCE-873 

[3] Jorge-Arulfo Quian-Ruiz, Christoph Pinkel, Jorg Schad, Jens Dittrich, RAFTing MapReduce: Fast recovery on the RAFT.In Serge Abiteboul, 
Klemens B& ouml; hm, Christoph Koch, Kian-Lee Tan, editors, Proceedings of the 27th International Conference on Data Engineermg, ICDE 
2011, Apri 11-16, 2011, Hannover, Germany. 


6.5.2 ”TaskTracker 容 错 


TaskTracker fit #2 ttt 
通常 非常 多 ， 设 计 合 到 
上， 分 别 是 超时 机 制 、 








的 TaskTracker 容 
灰 名 单 与 黑 
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行 来 自 JobTracker 的 各 利 
EH 
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结果 定时 汇报 给 








Ey 
TH 


并 将 命令 执行 
j 对 于 及 时 发 现存 如 





L 





























超时 机 制 是 一 种 在 分 布 式 环境 下 常 
从 而 启动 相应 的 故障 解决 方案 。 











障 ， 


口 TaskTracker 第 一 次 汇报 心跳 后 ， 

















的 发 现 服务 故障 的 方法 。 


Hadoop 也 采用 了 类 似 的 方法 发 现 


JobTracker 会 将 其 放 入 过 








E 问 题 的 节点 显得 非常 如 


Hl] FUExclude list- Include list. 


TE 





iu) 





如 果 一 种 服务 在 一 定时 间 未 响应 ， 






























































期 队列 trackerExpiryQueuej 











。 在 一 个 Hadoop 集 群 


Ho 








P, TaskTracker2¢ Œ: 
了 三 种 TaskTracker 容 错 机 














Hadoop 提 供 


则 可 认为 该 服务 出 现 了 故 


出 现 故 障 的 TaskTracker， 具 体 如 下 : 














并 将 其 加 入 网 络 拓扑 结构 中 。 

























































































口 TaskTracker 以 后 每 次 汇报 心跳 ，JobTracker 均 会 记录 最 近 心 跳 时 间 (TaskTrackerStatus.lastSeen) 

口 线程 expireJrackersIhread 周 期 性 地 扫描 过 期 队列 trackerExpiryQueue， 如 果 发 现 某 个 TaskIracker 在 10 分 钟 〈 可 通过 参数 
mapred.tasktracker.expiry.interva 配 置 ) 内 未 汇报 心跳 ， 则 将 其 从 集群 中 移 除 。 

移 除 TaskTracker 之 前 ，JobTracker 会 将 该 TaskTracker 上 所 有 满足 以 下 两 个 条 件 的 任务 杀 掉 ， 并 将 它们 重新 加 入 任务 等 待 队 列 
中 ， 以 便 被 调度 到 其 他 健康 节点 上 重新 运行 。 

条 件 1 任务 所 属 作业 处 于 运行 或 者 等 待 状态 

条 件 2 未 运行 完成 的 Task (包括 Map Task 和 Reduce Task) 或 者 Reduce Task 数 目 不 为 零 的 作业 中 已 运行 完成 的 Map Task. 

注意 ”所 有 运行 完成 的 Reduce Task 和 无 Reduce Task 的 作业 中 已 运行 完成 的 Map Task 无 须 重新 运行 ， 因 为 它们 将 结果 直接 写 入 
HDFS 中 ; 而 包含 Reduce Task 的 作业 中 已 运行 完成 的 Map Task 仍 需 重新 运行 ， 因 为 正常 的 TaskTracker 无 法 通过 HITP 获 取 死 亡 

















































































































































































































































































































TaskTracker 上 的 本 地 磁盘 数据 ， 具 体 原 理 可 参考 第 7 童 。 

2. 灰 名 单 与 黑 名 单机 制 

这 两 种 名 单 中 的 TaskTracker 均 不 可 以 再 接收 作业 ， 也 就 是 ， 被 宣判 死亡 《尽管 可 能 还 活着 ,但 由 于 短 时 间 内 性 能 表现 “大 
差 ”，JobTracker 不 得 不 让 它 “ 休 息 " 一 会 ) 。 

通过 启发 式 算法 推断 出 存在 问题 的 TaskTracker 被 加 入 灰 名 单 ， 一 段 时 间 之 后 ， 这 些 TaskTracker 将 重新 获得 一 次 接收 任务 的 机 
aes 

通过 用 户 设 定 的 脚本 监控 发 现存 在 问题 的 TaskTracker 被 加 入 黑 名单 ， 这 些 TaskTracker 不 会 再 “复活 ”， 直 到 监控 脚本 发 现 
TaskTracker 又 活 过 来 了 。 

C1) RA 

每 个 作业 在 运行 过 程 中 会 动态 生成 TaskTracker 黑 名 单 〈 一 个 TaskTracker 列 表 ) ， 而 位 于 黑 名 单 中 的 TaskTracker 将 不 会 再 有 运 
行 该 作业 的 任何 任务 的 机 会 。TaskTracker 黑 名 单 生 成 的 方法 是 ， 作 业 在 运行 过 程 中 记录 每 个 TaskTracker 使 其 失败 的 Task Attempt 数 
A, 一旦 该 数目 超过 mapred.max.tracker.failures (默认 是 4) ， 对 应 的 TaskTracker 会 被 加 入 该 作业 的 黑 名 单 中 。 





JobTracker 将 记录 每 个 TaskTracker 被 作业 加 入 号 


JobTracker 的 灰 名 单 中 : 














BH 








的 次 数 #blacklist。 


当 某 个 TaskTracker 同 时 满足 以 下 条 伯 
































F 时 ， 将 被 加 入 


条 件 1 ”#blacklist 大 小 超过 mapred.max.tracker.blacklists 值 (默认 为 4) 。 





条 件 2 ”该 TaskTracker 的 #blacklists 大 小 超过 所 有 TaskTracker 的 #blacklist 平 均值 的 mapred.cluster.average.blacklist.threshold (默认 是 
50%) 倍 。 








条 件 3 ”当前 灰 名 单 中 TaskTracker 的 数目 小 于 所 有 TaskTracker 数 目的 50%。 








JobTracker 为 每 个 潜在 存在 问题 的 TaskTracker(#blacklist 大 于 0〉 维 护 了 一 个 环形 桶 数据 结构 。 该 数据 结构 保存 了 最 近 一 段 时 
间 内 TaskTracker 对 应 的 #blacklist 值 ， 由 于 该 值 随 着 时 间 推 移 不 断 变 化 ， 因 此 TaskTracker 可 能 会 不 断 进出 灰 名 单 。 
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lastRotated 
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(now) 














图 6-6 环形 桶 数据 结构 








一 个 典 








型 的 环行 桶 数据 结构 〈 有 具体 参考 类 JobTrackerFauktmf) 如 图 6-6 所 示 。 默 认 情 况 下 ， 它 维护 了 最 近 





mapred.jobtracker.blacklst 人 But-timeout-window《〈 默 认 是 3 小 时 ) 时 间 内 某 个 TaskTracker 对 应 的 #blacklist 值 。 为 了 便于 计算 ， 环 形 桶 被 
分 成 若干 个 等 时 间 片 (由 参数 mapred.jobtracker.blacklist.fault-bucket-width 配 置 ， 默 认 是 15 分 钟 ) 长 度 的 桶 ， 所 有 桶 的 #blacklist 值 由 
整 型 数组 qumFaukts 中 维护， 同时 由 指针 lastRotated 指 向 最 近 一 次 更 新 所 在 桶 的 第 1 个 毫秒 位 置 ， 具 体操 作 如 下 : 





















































口 初始 化 操作 : 

















lastRotated= (time/bucketWidth) *bucketWidth; /* 其 中 ，time 为 当前 时 间 ， 
bucketWidth 为 桶 宽度 ， 经 初始 化 后 ，lastRotated 是 pucketWiqdth 的 整数 倍 */ 








口 checkRotation 操 作 : 将 lastRotated 到 某 个 新 时 间 点 timeStanp 之 间 的 桶 计数 器 (#blacklist〉 清 零 ， 同 时 将 lastRotated 移 动 到 新 时 
间 点 对 应 的 桶 第 一 毫秒 所 在 位 置 。 








void checkRotation (long timeStamp) { 

long diff=timeStamp-lastRotated; 

while (diff>bucketWidth) { 

Vi Last Rovatogd Aut FIBA SoHh 〈 它 即将 成 为 最 新 的 桶 ) 第 一 个 毫秒 的 位 置 








lastRotated+=bucketWidth; 


// 取 得 桶 下 标 


int idx= (int) ( (lastRotated/bucketWidth) 


/ eB, AS ABE BES 


numFaults [idx]=0; 


diff-=bucketWidth; 


} 
} 


SnumFaultBuckets) ; 





OinerFaultCount#i/E: 将 某 个 时 间 点 对 应 的 桶 计数 器 加 1， 对 应 代码 如 下 。 





void incrFaultCount (long timeStamp) { 


checkRotation (timeStamp) ; 


++numFaults [bucketIndex (timeStamp) ]; 


} 


int bucketIndex (long timeStamp) { 


return (int) ( (timeStamp/bucketWidth) 


} 


// 将 lastRotated~timeStamp 时 间 段 内 桶 计数 器 清 零 


SnumFaultBuckets) ; 


























































































































































































































(2) 黑 名 单 

Hadoop 人 允许 用 户 编写 一 个 脚本 Chealth check script) [1 监控 TaskTracker 是 否 健 康 (TaskTracker 可 能 仍然 活着 ， 但 是 不 健康 ， 
比如 资源 耗 光 、 关 键 服务 挂 掉 等 ) ， 并 由 TaskTracker 通 过 心跳 将 该 脚本 的 检测 结果 汇报 给 JobTracker， 一 旦 发 现 不 健 
康 ，JobTracker 会 将 该 TaskTracker 加 入 黑 名 单 中 ， 此 后 不 再 向 其 分 配 任务 ， 直 到 脚本 检测 结果 为 健康 。 有 具体 实现 见 7.3 节 。 

3.Exclude list 与 Include list 

Exclude st 是 一 个 非法 节点 列表 ， 所 有 位 于 该 列表 中 的 节点 将 无 法 与 JobTracker 连 接 〈 在 RPC 层 抛 出 异常 ) 。Include lst 是 一 个 
合法 节点 列表 (类 似 于 节点 白 名 单 ) ， 只 有 位 于 该 列表 中 的 节点 才 人 允许 向 JobTracker 发 起 连接 请 求 。 默 认 情 况 下 ， 这 两 个 列表 是 
空 的 ， 表 示人 允许 任何 节点 接 入 JobTracker。 这 两 个 名 单 中 的 节点 均 由 管理 员 配 置 ， 并 可 以 动态 加 载 生效 。 

管理 员 可 在 配置 文件 mapred-site.xml 中 配置 Exclude list 和 Include lst， 一 个 简单 的 实例 如 下 : 

<property> 


<name>mapred.hosts</name> 
<value>/etc/hadoop hosts/include hosts</valu 


< description> 合 法 节点 所 在 文件 ， 如 果 文 件 为 空 MERER 


<property> 








<name>mapred.hosts.exclude</name> 
<value>/etc/hadoop hosts/exclude hosts</value> 


<description> 非 合法 节点 所 在 文件 ， 如 果 文 件 为 空 或 者 未 配置 ， 则 表 





， 一 由 表示 所 有 节点 均 合法 。 </description></property> 





示 所 有 节点 均 合 法 。<=/description></property> 





其 中 ，include_hosts 和 exclude_hosts 两 个 文件 均 保 存 了 








一 个 节点 host 列 表 ， 实 例如 下 : 
































































































































node0000 
node0001 
node0002 
注意 ” 黑 名 单 与 非法 节点 列表 是 两 个 不 同 的 概念 ， 区 别 主要 有 两 个 。 
口 范 围 不 同 : 黑 名 单 是 TaskTracker 级 别 的 ， 而 非法 节点 列表 是 host (一 个 host 上 可 以 有 多 个 TaskTracker) 级 别 的 。 
口 任务 运行 结果 不 同 : 如 果 一 个 TaskTracker 被 动态 添加 到 黑 名 单 中 ， 则 它 上 面 正在 运行 的 任务 可 以 正常 运行 结束 (但 不 会 为 
之 分 配 新 任务 ) ， 但 被 加 入 非法 节点 列表 的 节点 则 不 同 ， 它 上 面 所 有 正在 运行 的 任务 将 无 法 成 功 运行 完成 
综 上 所 述 ， 影 响 一 个 Hadoop 集 群 中 TaskTracker 数 量 的 因素 如 图 6-7 所 示 ， 管 理 员 可 根据 需要 ， 将 一 些 节 点 动态 加 入 集群 或 者 
移出 集群 ， 以 更 好 地 维护 Hadoop 集 群 或 者 提升 它 的 计算 能 






















Dead TaskTrackers 


Exclude list 





Node<->TaskTrackers 


图 6-7 Hadoop 集 群 中 TaskTracker 数 量变 化 影响 因素 
[1] https//ssues. apache. org/jira/browse/MAPREDUCE-21 1 











6.5.3 ”Job/Task 容 错 


1.Job 容 错 机 第 
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在 MapReduce 框 架 中 ， 一 个 作业 会 被 分 解 成 多 个 任务 ， 当 所 有 任务 成 功 运行 完成 时 ， 作 业 才 算 运 行 成 功 。 但 在 很 多 实际 应 用 
场景 中 ， 比 如 搜索 引擎 日 志 分 析 、 网 页 处 理 等 ， 由 于 数据 量 巨 大 ， 丢 奔 一 小 部 分 数据 可 能 并 不 会 影响 最 终结 果 。 正 因为 如 此 ， 为 
支持 容错 ，MapReduce 人 允许 丢弃 部 分 输入 数据 而 保证 绝 大 部 分 数据 有 效 ， 也 就 是 说 ，MapReduce 可 允许 部 分 任务 失败 ， 而 其 对 应 
的 处 理 结果 不 再 计 入 最 终 的 结果 。 

































































思 | 



















































































Hadoop 为 作业 提供 了 两 个 可 配置 参数 : mapred.maxmap.failares.percent 和 mapred.max.reduce.failares.percent。 用 户 提交 作业 时 可 
通过 这 两 个 参数 设 定 允 许 失败 的 Map 任 务 和 Reduce 任 务 数 所 占 总 任务 数 的 百分比 。 默 认 情 况 下 ， 这 两 个 参数 值 均 为 0， 即 只 要 有 
一 个 Map 任 务 或 者 Reduce 任 务 失败 ， 整 个 作业 便 运 行 失 败 。 



















































































2.Task 容 错 机 币 





= 

















前 面 提 到 ， 每 个 Task 运 行 状 况 由 对 应 的 一 个 TaskInProgress 对 象 跟踪 ， 它 允许 一 个 Task 尝 试 运行 多 次 ， 每 次 称 为 一 个 运行 尝 
试 ， 即 Task Attempt。Hadoop 提 供 了 两 个 可 配置 参数 : mapred.map.max.attempts 和 mapred.reduce.max.attempts。 用 户 提交 作业 时 可 通 
过 这 两 个 参数 设 定 Map Task 和 Reduce Task 党 试 运行 最 大 次 数 。 默 认 情 况 下 ， 这 两 个 值 均 为 4， 即 每 个 Task 可 最 多 运行 4 次 ， 如 果 洽 
试 4 次 之 后 仍旧 未 运行 成 功 ， 则 TaskInProgress 对 象 将 该 任务 运行 状态 标注 为 FAILED。 























































































































未 运行 成 功 的 Task Attempt 可 分 为 两 种 : kiled task 和 failed task， 它 们 分 别 对 应 状态 KILLED 和 FAILED。 其 中 ，killed task 是 
MapReduce 框 架 主动 杀 死 的 Task Attempt， 一 般 产生 于 以 下 3 种 场景 。 

















口 人 为 杀 死 Task Attempt: 用 户 使 用 命令 “bin/hadoop job-kilHtask<task- 辽 > 将 一 个 Task Attempt 杀 死 。 





























口 磁 盘 空 间或 者 内 存 不 够 : 任务 运行 过 程 中 ， 出 现 磁盘 或 者 内 存 磁 盘 不 足 ，MapReduce 框 架 需 采用 一 定 策略 杀 死 若干 个 Task 
以 释放 资源 。 其 选择 杀 死 Task 的 策略 是 优先 选择 Reduce Task， 其 次 是 进度 最 慢 的 Task。 
































O TaskTracker £k: 如 果 TaskTracker 在 一 定时 间 内 未 向 JobTrackerE 报 心跳 ， 则 JobTracker 认 为 该 TaskTracker 已 经 死 掉 ， 它 上 
面 的 所 有 任务 将 被 杀 掉 。 





























Failed task 是 自身 运行 失败 的 Task Attempt， 通 常 产生 于 以 下 几 种 场景 。 


























口 人 为 使 Task Attempt 失 败 : 用 户 使 用 命令 “binhadoop job-fail-task < task-id>’{#’—Task Attempt 杀 死 。 




















口 本 地 文件 读 写 错误 : Task 和 运行 过 程 中 ， 由 于 磁盘 坏 道 等 原因 ， 导 致 文件 读 写 错误 。 
































DShufle 阶 段 错 误 : Reduce Task 从 Map Task 端 远程 读 取 数 据 过 程 中 出 错 。 





























口 Counter 数 目 过 多 : 用 户 自 定义 的 Counter 或 者 Counter Group 数目 超过 系统 要 求 的 上 限 。 












































口 一 定时 间 内 未 汇报 进度 : 由 于 程序 Bug 或 者 数据 格式 问题 ， 任 务 在 一 定时 间 间 隔 《〈 可 通过 参数 mapred.task.timeout 配 置 ， 默 
认 10 分 钟 ) 内 未 汇报 进度 。 

































































口 使 用 内 存量 超过 期 望 值 : 用 户 提交 作业 时 可 指定 每 个 Task 预 期 使 用 的 内 存量 ， 如 果 在 运行 过 程 中 超过 该 值 ， 则 会 运行 失 


















































口 任务 运行 过 程 中 的 其 他 错误 : 如 初始 化 错误 ， 其 他 可 能 的 致命 错误 。 














Failed task 和 killed task 除 了 产生 场景 不 同 以 外 ， 还 有 以 下 两 个 重要 区 别 。 


口 调度 策略 : 一 个 Task Attempt 在 某 个 节点 上 运行 失败 之 后 ， 调 度 器 便 不 会 再 将 同一 个 Task 的 Task Attempt 分 配给 该 节点 ; 而 


一 个 Task Attempt 被 杀 掉 后 ， 仍 可 能 被 调度 到 同一 个 节点 上 运行 。 
， 也 就 是 说 ， 任 何 一 个 Task 允 许 的 失败 次 数 是 有 限 的 ， 而 对 于 killed 









































尝试 次 数 ， 前 面 提 到 的 Task 容 错 机 制 是 针对 人 iled Task 的 
并 不 存在 问题 ， 因 此 会 不 断 尝试 运行 ， 直 到 运行 成 功 。 









































Task， 由 于 它们 是 被 框架 主动 杀 死 的 ， 它 们 自身 





























6.5.4 Record 容错 






































MapReduce 采 用 了 和 达 代 式 处 理 模 型 。 它 将 输入 数据 解析 成 一 个 个 key/value 进 行 迭 代 处 理 ， 然 而 ， 在 数据 处 理 过 程 中 ， 可 能 由 
于 存在 一 些 坏 记 录 ， 导 致 任务 总 是 运行 失败 。 为 此 ，MapReduce 引 入 了 Record 级 别 的 容错 机 制 。 它 能 够 "有 记忆 ?地 运行 任务 ， 即 
它 会 记录 前 几 次 任务 尝试 中 导致 任务 失败 的 Record， 并 在 下 次 运行 时 自动 跳 过 这 些 坏 记 录 出 。 

































































在 实际 应 用 场景 中 ， 有 多 种 原因 使 得 坏 记 录 导 致 任务 运行 失败 ， 常 见 原因 有 两 个 : 





























口 某 些 记录 的 key 或 者 value 超 大 ， 导 致 内 存 溢 出 〈Out OfMemory,OOM) 。 









































口 用户 应 用 程序 使 用 了 第 三 方 的 jar 包 或 者 静态 库 /动态 库 〈 不 可 获取 源 代 码 ) ， 由 于 这 些 程序 中 存在 Bug， 使 得 某 些 记录 总 是 






































处 理 失 败 ， 进 而 导致 任务 运行 崩溃 或 者 任务 悬挂 站 (一旦 任务 长 时 间 无 响应 ，TaskTracker 会 将 其 杀 掉 ) 。 



































对 于 第 一 种 情况 ，MapReduce 允 许 用 户 在 InputFormat 组 件 中 设置 key 或 者 Value 的 最 大 长 度 ( 如 果 使 用 TextInputFormat， 可 配置 
参数 mapred.linerecordreader.maxlength) ， 一 旦 超过 该 长 度 ， 则 直接 截断 字符 串 以 防止 OOM。 
























































对 于 第 二 种 情况 ，MapReduce 采 用 了 一 种 智能 的 有 记忆 尝试 运行 机 制 。 前 面 提 到 ， 每 个 任务 会 尝试 运行 多 次 ， 直 到 任务 运行 
成 功 或 者 达到 运行 次 数 上 限 。 对 于 一 个 任务 ，MapReduce 会 先 尝试 运行 几 次 ， 如 果 总 是 失败 ， 则 会 自动 进入 skip mode 模 式 。 在 该 
模式 下 ， 每 个 Task Attempt 不 断 将 接 下 来 要 处 理 的 数据 区 间 发 送 给 TaskTracker， 再 由 TaskTracker 通 过 心跳 发 送 给 JobTracker， 医 
此 ，JobTracker 时 刻 保存 了 尚未 处 理 完 成 的 数据 所 在 区 间 ， 这 样 ， 如 果 因 某 条 坏 记 录 导 致 任务 运行 失败 ，JobTracker 很 容易 推断 出 
坏 记录 所 在 区 间 。 当 重新 运行 失败 任务 时 ，JobTracker 将 过 去 识别 出 的 所 有 坏 记 录 区 间 ' 告 诉 ? 新 的 Task Attempt， 从 而 可 在 运行 过 
程 中 自动 跳 过 这 些 坏 记录 区 间 。 通 过 这 种 机 制 ，Hadoop 以 丢失 少量 坏 记 录 为 代价 保证 整个 任务 运行 成 功 ， 这 对 于 很 多 数据 密集 
型 作业 《比如 日 志 分 析 ) 是 可 以 接受 的 。 
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j 户 可 通过 SkipBadRecords 类 控制 该 机 币 








1。 它 提供 了 表 6-3 所 示 的 儿 个 可 配置 参数 。 





表 6-3 跳 过 坏 记 录 功 能 控制 参数 





参数 名 称 默认 值 

mapred.skip.attempts.to.start.skipping 当 任 务 失 败 次 数 达 到 该 值 时 ， 才 会 进入 
skip mode， 即 启用 跳 过 坏 记 录 功 能 

mapred.skip.map.max.skip.records 用 户 可 通过 该 参数 设置 最 多 人 允许 跳 过 的 记 |10《 不 启用 跳 过 坏 记 录 功 能 ) 
KAHA 

mapred.skip.reduce.max.skip.groups 用 户 可 通过 该 参数 设置 Reduce Task 最 多 10 (不 启用 跳 过 坏 记 录 功 能 ) 
允许 跳 过 的 记录 数目 

mapred.skip.out.dir 检测 出 的 坏 记 录 存 放 目 东 (一 般 为 HDFS |${mapred.output.dir}/ logs/ 


路 径 )。Hadoop 将 坏 记 录 保 存 起 来 以 便于 用 


户 调试 和 追踪 





设 mapred.skip.attempts.to.startskipping 值 为 k (k>=0) ，mapred.skip.map.max.skip.records 值 为 N (N> 
0) ，mapred.map.max.attempts 值 为 M (M>k) ，failedRanges 为 坏 记 录 区 间 列 表 ， 保 存 了 已 运行 失败 的 Task Attemp 夫 测 出 的 坏 记 录 
区 间 。 以 Map Task 为 例 ， 跳 过 坏 记 录 工 作 流程 可 分 为 以 下 几 个 步 又 : 
































步骤 1 每 个 任务 先 党 试 运行 k 次 ， 如 果 任 务 运行 成 功 则 停止 ， 否 则 进入 skip mode， 令 jk+1 并 进入 步 又 2。 

















步骤 2 第 i 个 Task Attempt 不 断 地 〈 通 常 是 每 处 理 一 条 汇报 一 次 ) 将 接 下 来 要 处 理 的 数据 区 间 Range[offset, length] 中 汇报 给 
TaskTracker, TaskTracker 将 之 保存 到 变量 nextRecordRange 中 。 需 要 注意 的 是 ，Task Attempt 会 判断 接 下 来 要 处 理 的 数据 是 否 在 坏 记 
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录 区 间 列 表 failedRanges 中 ， 如 果 是 ， 则 跳 过 对 应 区 间 。 








步骤 3 ”TaskTracker 通 过 心跳 将 每 个 任务 最 近 的 nextRecordRange 值 汇报 给 JobTracker。 























步骤 4 ”如 果 第 i 个 Task Attempt 运 行 失败 ， 则 JobTracker 将 查看 最 近 一 次 数据 处 理 区 间 长 度 是 否 超 过 N， 如 果 是 ， 则 将 其 不 断 二 
等 分 ， 直 到 区 间 长 度 小 于 N， 并 依次 选择 这 几 个 区 间作 为 新 Task Attempt 的 输入 数据 ， 以 期 望 这 些 Task Attempt 探 测 出 失败 记录 所 
在 的 区 间 。 设 其 中 第 j 个 Task Attempt 运 行 失败 ， 则 它 所 处 理 的 数据 区 间 即 为 坏 记录 所 在 区 间 ，JobTracker 将 该 区 间 添 加 到 坏 记 录 区 
间 列 表 failedRanges 中 。 




























































































步骤 5 Qi GH) ， 并 将 最 新 的 failedRanges 值 作为 下 一 个 Task Attempt 的 已 知 信息 ， 重 复 步 











又 2 一 4， 直 到 这 =M 或 者 任务 运 




























































































下 面 介 绍 Task Attempt 如 何 锁定 将 要 处 理 的 数据 区 间 。 对 于 每 个 处 于 skip mode 的 Task Attempt 而 言 ， 均 包含 两 个 指针 用 于 锁定 
接 下 来 要 处 理 的 数据 区 间 : currentRecStartIndex 和 和 nextRecIndex。 它 们 分 别 表示 下 一 条 将 被 RecordReader 解 析 的 数据 记录 索引 (前 面 
的 数据 已 确认 被 成 功 处 理 完 ) 和 已 被 RecordReader 解 析 但 未 交 给 Mapper/Reducer 处 理 的 记录 索引 。 区 间 Range[currentRecStartIndex, 
nextRecIndex-currentRecStartIndex+1] 为 将 要 处 理 的 数据 区 间 。 其 中 ，nextRecIndex 值 的 增加 由 Hadoop 框 架 控制 ， 而 
currentRecStartIndex 通 常 由 用 户 控 制 ， 它 的 值 随 着 Hadoop 内 部 已 定义 好 的 两 个 计数 器 值 的 改变 而 改变 ， 这 两 个 计数 嚣 分别 是 位 于 
SkippingTaskCounters 组 的 MapProcessedRecords 和 ReducerProcessedRecords 中 。 这 两 个 计数 器 在 不 同类 型 的 应 用 程序 中 控制 方法 不 
同 。 以 Map Task 为 例 ， 对 于 Java 应 用 程序 而 言 ， 如 果 采 用 默认 的 MapRunner， 则 每 处 理 完 一 条 记录 后 ， 会 自动 对 
MapProcessedRecords 计 数 器 加 1; 然而 对 于 Pipes/Streaming 应 用 程序 而 言 ， 由 于 数据 处 理 逻 辑 通 常 由 另外 一 种 语言 ( 非 Java 语 言 ) 
实现 ， 用 户 可 能 在 Mapper 中 对 记录 进行 缓存 ， 因 而 需要 用 户 在 应 用 程序 中 根据 实际 逻辑 增加 该 计数 器 值 。 
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为 了 帮助 读者 更 深入 了 解 跳 过 坏 记 录 的 工作 原理 ， 我 们 接 下 来 举 一 个 简单 的 例子 。 假 设 用 户 需 要 处 理 一 个 文本 文件 skip-bad- 


records-test.txt， 它 的 每 一 行 是 一 个 字符 串 ， 如 果菜 一 行内 容 是 “Bad”， 则 认为 它 是 坏 记 录 ， 否 则 是 正常 记录 ， 直 接 输 出 即 可 。 文 
件 内 容 举 例如 下 : 





























































































































为 了 方便 ， 我 们 使 用 Awk 语 言 编 写 mapper.awk 脚 本 作为 Mapper: 





#! /bin/awk-f 

{ 

if ($1~/^bad$/) {# 这 一 行 是 坏 记录 
exit 1; PHRMA RBH 
selse{ 
print"reporter: counter: SkippingTaskCounters, MapProcessedRecords, 1"\ 
>"/dev/stderr"; # 通 过 标准 错误 输出 修改 Counter 

print$1; # 输 出 结果 


} 





























我 们 使 用 Hadoop Streaming 运 行 以 上 程序 ，Shel 运 行 脚本 如 下 : 











HADOOP_HOME=/opt/dongxicheng/hadoop-1.0.0 
SHADOOP_HOME/bin/hadoop jar\ 

SHADOOP HOME/contrib/streaming/hadoop-streaming-1.0.0.jar\ 
-D mapred. job.name="Skip-Bad-Records-Test"\ 

-D mapred.map.tasks=1\ 

-D mapred. reduce.tasks=0\ 

-D mapred.skip.map.max.skip.records=1\ 

-D mapred.skip.attempts.to.start.skipping=2\ 
-D mapred.map.max.attempts=6\ 
-input"/test/input/skip-bad-records-test.txt"\ 
-output"/test/output"\ 

-mapper"mapper. awk" 








-file"mapper.awk" 























假设 输入 文件 中 只 在 361 行 〈 从 第 0 行 开始 计算 ) 中 有 一 条 坏 记 录 。 根 据 跳 过 坏 记 录 算 法 ， 仅 有 的 一 个 Map Task 需 要 尝试 运行 
5 次 才 会 最 终 运行 成 功 ， 如 图 6-8 所 示 ， 过 程 如 下 : 

















D 前 两 个 Task Attenmpt 尝 试 处 理 该 文件 ， 但 每 次 到 361 行 均 异常 退出 ， 导 致 任务 运行 失败 。 




















2) 从 第 三 个 Task Attempt 开 始 进 入 skip mode。 该 Task Attempt 在 处 理 数 据 过 程 中 ， 会 不 断 将 接 下 来 的 数据 处 理 区 间 汇 报 给 
TaskTracker， 再 由 TaskTracker 汇 报 给 JobTracker， 当 处 理 到 第 361 行 时 出 现 错误 ， 此 时 ，JobTracker 最 后 收 到 的 数据 处 理 区 间 是 


Ranse[361，2] 办 。 







































































3) 由 于 数据 处 理 区 间 长 度 超过 1 (一 次 最 多 可 跳 过 坏 记 录 条 数 为 1) ，JobTracker 采 用 二 分 法 将 该 区 间 分 裂 成 两 段 ， 分 别 是 
Range[361，1] 和 Range[362，1]， 并 将 第 四 个 Task Attempt 作 为 测试 任务 ， 指 定 其 数据 处 理 区 间 为 Range[361，1]， 即 跳 过 区 间 
Range[0，361] 和 Range[362，oo]， 只 处 理 第 361 行 记录 。 
























































4) 第 四 个 Task Attempt 仍 然 运 行 失败 ， 此 时 JobTracker 可 推断 出 Range[361，1] 为 坏 记 录 所 在 区 间 ， 同 时 将 Range[362，1] 标 注 
为 正常 数据 区 间 ， 并 将 该 信息 传递 给 第 五 个 Task Attempt。 














5) 第 五 个 Task Attempt 在 运行 过 程 中 跳 过 坏 记 录 区 间 Range[361，1]， 最 终 运 行 成 功 。 
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failedRanges ; 
skipping ; 
} 


Ask to lauch TaskStatus. 
a task Heartbeat setNextRecordRange 


TaskTracker0 TaskTrackerl TaskTracker2 TaskTracker3 TaskTracker4 
Report 
Status Next 
Launch Update Record 
Range 








task-attempt 1 task-attempt 2 task-attempt 3 task-attempt 4 task-attempt 5 
Execution Without Execution With 
bad-record -skipping bad-record-skipping 





图 6-8 一 个 跳 过 坏 记 录 实 例 
[1] https//issues. apache.org/jira/browse/HADOOP-153 

D] 任务 悬挂 是 一 种 常见 的 现象 ， 通 常 对 外 表现 为 任务 阻塞 ， 不 再 汇报 进度 和 状态 。 
[3] Range[ofiset, length]: 表示 一 个 数据 处 理 区 间 ， 其 中 offset 为 区 间 中 第 一 条 记录 在 整个 数据 块 中 的 偏 移 量 〈 以 记录 为 单 

































































位 ) ，]lengtp 为 区 间 长 度 。 














[4 1 











于 存在 操作 系统 缓存 ，Aw 尿 脚本 程序 向 Hadoop 术 








EE 架 传 递 计数 器 时 不 能 一 个 一 个 传递 ， 即 数据 


区 间 长 度 大 于 1。 





6.5.5 ”磁盘 容错 











在 MapReduce 中 ， 任 务 需要 频繁 往 磁盘 上 写 数 据 ， 比 如 Map Task 需 将 数据 写 到 本 地 磁盘 ，Reduce Task 需 将 数据 写 到 最 终 的 
HDFS 上 。 由 于 磁盘 故障 率 明显 高 于 其 他 硬件 (比如 内 存 、CPU 等 ) ， 因 而 设计 合理 的 磁盘 容错 机 制 对 于 成 功 运行 一 个 数据 密集 
型 作业 尤为 重要 。 













































































MapReduce 中 存在 多 个 可 配置 选项 用 于 设 定 各 种 数据 输出 目录 ， 这 些 选项 大 多 同时 支持 配置 多 个 目录 ， 为 了 提高 写 效率 和 人 负 
载 均衡 ， 用 户 通常 将 不 同 磁盘 挂 载 到 这 些 目录 ， 一 个 典型 的 架构 如 图 6-9 所 示 。 





























TaskTracker 








图 6-9 磁盘 容错 架构 








ES 


TaskTracker 有 多 种 可 选 策略 可 将 数据 均衡 地 写 到 这 些 磁 盘 ， 比 如 轮 询 选择 、 随 机 选择 、 最 多 剩余 空间 磁盘 优先 等 。 当 前 
TaskTracker 实 现 中 采用 了 轮 询 策 略 ， 即 轮流 选择 磁盘 作为 任务 的 输出 目录 所 在 位 置 。 该 策略 与 随机 选择 和 最 多 剩余 空间 磁盘 优先 
策略 比较 ， 可 明显 降低 产生 写 热点 《大量 任 务 同 时 往 一 个 磁盘 上 写 数据 ) 的 可 能 性 ， 有 利于 实现 写 负载 均衡 。 


































































































(1) TaskTracker 采 用 的 机 制 























TaskTracker 允 许 用 户 设 定 以 下 两 个 参数 以 保证 节点 上 有 足够 的 可 用 磁盘 空间 ， 防 止 任务 因 磁 盘 空 间 不 足 而 运行 失败 。 






































口 mapred. localdirminspacestart，TaskTracker 需 要 保证 的 最 小 可 用 磁盘 空间 。 只 有 当 可 用 磁盘 空间 超过 该 参数 值 时 ， 才 会 接收 
新 任务 。 


























口 mapred. local.dir.minspacek 训 TaskTracker 会 周期 性 检查 所 在 节点 的 剩余 磁盘 空间 ， 一 旦 低 于 该 闵 值 ， 便 会 按照 一 定 策略 杀 
掉 正在 运行 的 任务 以 释放 磁盘 空间 。 
























































对 于 MapReduce 而 言 ， 最 重要 的 目录 是 用 于 保存 Map Task 中 间 结 果 的 目录 ， 它 由 参数 mapred.localdirs 指 定 。TaskTracker 刚 启动 
时 ， 首 先 会 检查 这 些 目录 的 健康 状况 ， 并 将 健康 目录 保存 下 来 以 便 使 用 ， 这 之 后 ， 它 还 会 周期 性 《周期 由 参数 
mapred.disk.healhCheckerinterval 指 定 ， 默 认 是 60 秒 ) 检查 各 个 目录 的 健康 状况 ， 一 旦 发 现 某 个 正常 目录 出 现 故 障 〈( 比 如 属性 变 为 
RED ， 则 会 重新 对 自己 进行 初始 化 (该 过 程 与 JobTracker 向 TaskTracker 发 送 ReinitTrackerAction 命 令 后 ，TaskTracker 重 启 过 程 一 
致 ， 涉 及 清理 磁盘 空间 、 初 始 化 各 种 服务 等 ) 。 
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(2) JobTracker 采 用 的 机 制 














JobTracker 上 保存 了 所 有 任务 的 运行 时 信息 。 它 可 以 通过 已 经 运行 完成 的 任务 产生 的 数据 量 估算 出 其 他 同 作业 任务 需要 的 磁 
盘 空 间 ， 这 可 以 防止 因为 某 个 节点 磁盘 空间 不 足以 容纳 某 个 任务 运行 结果 而 造成 任务 运行 失败 。 


















































JobTracker 采 用 的 数据 量 估算 方法 如 下 。 





























当 一 个 作业 已 经 运行 完成 的 Map Task 数 目 超过 Map Task 总 数 的 1/10 时 ，JobTracker 开 始 估算 剩余 Map Task 产 生 的 数据 量 ， 它 采 
了 以 下 简单 的 线性 模型 : 






































completedMapsOutputSize 
estimatedTotalMapOutput=inputSize x ——WY_____—_ 
completedMapsInputSize 


estimatedMapOutput=estimatedTotalMapOutput/numMapTasks 





其 中 ，inputSize 表 示 输 入 数据 总 量 ，completedMapsInputSize/completedMapsOutputSize 表 示 所 有 已 经 运行 完成 的 Map Task 的 总 输 
入 数据 量 和 总 输出 数据 量 ， 最 后 乘 2 表 示 输 出 数据 量 会 翻 倍 〈 保 守 估 计 ) 。 


























在 此 基础 上 ， 可 估算 出 Reduce Task 的 输入 数据 量 : 

















estimatedReduceInput=estimatedTotaIMapOutput/numReduceTasks 

















如 果 估 算 到 某 个 Map/Reduce Task 产 生 的 数据 量 或 者 输入 的 数据 量 超过 某 个 TaskTracker 剩 余 磁盘 空间 ， 则 不 会 将 该 Task 分 配给 
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6.6 任务 推测 执行 原理 














在 分 布 式 集 群 环境 下 ， 因 为 程序 Bug、 负 
一 致 。 有 些 任 务 的 运行 速度 可 能 明显 慢 于 其 他 









































载 不 均衡 或 者 资源 分 布 不 均等 原因 ， 会 造成 同一 个 作业 的 多 个 任务 之 间 运 行 速 度 不 




















任务 〈 比 如 一 个 作业 的 某 个 任务 进度 只 有 50%， 而 其 他 所 有 任务 已 经 运行 完毕 ) ， 























则 这 些 任务 会 拖 慢 作业 的 整体 执行 进度 。 为 了 避免 这 种 情况 发 生 ，Hadoop 采 用 了 推测 执行 (Speculative Execution) 机 制 。 它 根据 














一 定 的 法 则 推测 出 “ 拖 后 腿 ” 的 任务 ， 并 为 这 样 的 
































最 先 成 功 运行 完成 任务 的 计算 结果 作为 最 终结 果 








不 。 








在 MapReduce 必 用 程序 中 ， 用 户 可 分 别 通过 参 
制 是 否 对 Map Task 和 Reduce Task 启 用 推测 执行 功能 。 默 认 情况 下 ， 















































6.6.1 计算 模型 假设 


E 务 启动 一 个 备份 任务 ， 让 该 任务 与 原始 任务 同时 处 理 同 一 份 数 据 ， 并 最 终 选用 























数 mapred.map.tasks.speculative.execution 和 mapred.reduce.tasks.speculative.execution 控 
这 两 个 参数 均 为 tue， 表 示 启 用 该 功能 。 


























Hadoop 在 设计 之 初 隐 含 了 一 些 假 设 ， 而 正 是 这 些 假设 影响 了 Hadoop 最 初 的 推测 执行 设计 算法 。 总 结 起 来 ， 共 有 以 下 5 个 假 





设 : 


口 每 个 节点 的 计算 能 力 是 一 样 的 。 


口 任务 的 执行 进度 随时 间 线性 增加 。 

















口 启动 一 个 备份 任务 的 代价 可 以 忽略 不 计 。 














口 一 个 任务 的 进度 可 以 表示 成 已 完成 工作 量 


























占 总 数据 量 《〈 任 务 对 应 的 数据 分 片 大 小 ) 的 比 

















progress = | 





例 ; 对 于 Reduce Task 而 言 


M/N, 
1/3x(K+M/N), 














其 中 ，M 表 示 已 读 取 的 数据 量 ，N 表 示 总 数据 量 ; K=0, 1, 2 

















量 占 总 工作 量 的 比例 〈 位 于 0 一 ! 之 间 ) 。 对 于 Map Task 而 言 ， 可 表示 成 已 读数 据 量 











ml 

















言 ， 可 将 其 分 为 三 个 子 阶 段 : Shufle、Sort 和 Reduce， 每 个 





阶段 各 占 总 时 间 的 13。 在 每 个 阶段 内 部 ， 其 进度 的 计算 方法 跟 Map Task 一 样 ， 总 结 如 下 : 


For Map Task 
For Reduce Task 


分 别 对 应 Shufle、Sort 和 Reduce 三 个 阶段 。 比 如 ， 一 个 Reduce 


Task 位 于 Reduce 阶 段 ， 且 已 读 取 数 据 量 为 120 MB， 总 数量 为 200 MB， 则 进度 为 /3x (2+120/200) =86.7%. 





口 同 一 个 作业 同 种 类 型 的 任务 工作 量 是 

















很 明显 ， 这 些 假设 完全 是 基于 同 构 集 群 和 

















一 样 的 ， 所 用 总 时 间 相同 。 


负载 均衡 的 前 提 下 ， 


计算 量 差距 很 大 ) ， 则 很 多 机 制 将 会 产生 问题 。 





一 旦 








> m 


群 异 构 或 者 负载 不 均衡 (比如 不 同 Reduce Task 任 务 之 间 


6.6.2 ”1.0.0 版 本 的 算法 








如 果 一 个 任务 满足 以 下 条 件 ， 则 会 为 该 任务 启动 一 个 备份 任务 : 














口 该 任务 尚未 进入 skip mode《〈 由 于 推测 执行 机 制 和 跳 过 坏 记 录 机 制 均 会 减 慢 任 





























个 功能 ) o 


D 

















于 任意 一 个 任务 ji 如 果 满 足 : 














progress[i|<progress,, 


# rh, progress, rogress [1 Ji 
“Ze 


WES ENEMIES, RETNA S MES 












































当 该 任务 的 某 个 Task Attempt 成 功 运行 完成 后 ，JobTracker 会 杀 掉 另外 一 个 Task Attempt. 





该 版 本 实现 的 推测 执行 功能 存在 很 多 问题 ， 以 下 是 几 个 常见 问题 。 


























oO 











此 时 总 不 会 启动 备份 任务 。 
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口 缺 乏 保证 备份 任务 执行 速度 的 机 制 ; 
































证 备份 任务 的 运行 速度 不 低 于 原始 Task Attempt， 否 则 将 失去 启动 备份 任务 的 意义 。 





























口 参数 不 可 配置 : 比如 上 面 的 数值 “60 秒 ”和 “20%% 均 不 可 配置 ， 这 不 能 满足 














务 执行 进度 ， 考 虑 到 性 


—20% 











口 该 任务 没有 其 他 正在 运行 的 备份 任务 (当前 Hadoop 最 多 允许 一 个 任务 同时 启动 两 个 Task Attempt) 。 


适用 情况 考虑 不 全 : 当 作业 的 大 部 分 任务 已 经 运行 完成 时 ， 如 果 存 在 若干 个 TaskAttempt 的 运行 进度 


FY 
sF 








由 于 新 启动 的 备份 任务 需要 首先 处 理 原始 Task Attempt 已 经 处 理 






































口 该 任务 已 经 运行 时 间 超过 60 秒 且 当 前 正在 运行 的 Task Attenmmpt 沙 后 (同一 个 作业 所 有 Task Attempt 的 ) 平均 进度 的 20%， 


于 或 者 超过 80%， 








居 此 








完 的 数据 ， 








用 户 根 和 











Loiz 











JE 


数 的 要 求 。 


ae 
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则 


保 


6.6.3 ”0.21.0 版 本 的 算法 


为 了 解决 1.0.0 版 本 中 存在 的 问题 ，Hadoop 0.21.04 H 
用 了 基于 任务 运行 速度 和 但 





考虑 不 全 ?问题 ， 它 采 
































保证 备份 任务 执行 速度 的 机 制 ? 问 题 ， 它 根据 历史 介 
参数 不 可 配置 ”问题 ， 





备份 任务 分 配给 快 节点 ;对 了 












































照 自己 的 应 用 特点 和 集群 特点 定 和 
1. 配 置 选项 





Hadoop 0.21.0 中 增加 了 三 个 配置 选项 ， 用 





判 相应 的 参数 值 。 





















































上 了 新 的 算法 LATE (Longest Approximate Time to End) (1 。 对 于 “ 适 
F 务 最 大 剩余 时 间 的 策略 ， 尽 可 能 地 提高 发 现 '“ 物 后 腿 ? 尾 务 的 可 能 性 ， 对 于 "缺乏 


E 务 运行 速度 对 节点 进行 性 能 评测 ， 以 识别 出 快 节点 和 慢 节 点 ， 




















情况 








并 将 新 启动 的 



































它 增加 了 多 个 配置 选项 ， 使 一 些 常量 数据 尽 可 能 地 可 配置 ， 进 而 方便 用 户 按 












































(1) mapreduce. job.speculative.slownodethreshold 











户 在 提交 某 个 作业 时 可 根据 需要 指定 这 三 个 参数 值 








o 














这 个 参数 用 于 定义 该 作业 在 任意 一 个 TaskTracker 上 已 运行 完成 任务 的 平均 进度 增长 率 ( 一 个 任务 在 单位 时 间 内 运行 进度 的 增 

















ok 




















量 ) 与 所 有 已 运行 完成 任务 的 平均 进度 增长 率 的 最 大 允许 差 

















E 《标准 方差 的 倍数 ) 。 如 果 超 过 该 立 值 ， 则 认为 对 于 该 作业 而 


言 ， 该 TaskTracker 性 能 过 低 ， 不 会 在 其 上 启动 一 个 备份 任务 。 该 配置 选项 默认 值 是 1， 表 示 如 果 一 个 TaskTracker 上 已 运行 完成 任 





务 的 平均 进度 增长 率 与 所 有 
不 会 在 该 TaskTracker 上 为 该 作业 启动 人 








己 运 行 完 成 人 

















(2) mapreduce. job.speculative.slowtaskthreshold 




















这 个 参数 用 于 定义 该 作业 的 人 
的 倍数 ) 。 当 超过 该 阔 值 时 ， 则 认为 该 人 
长 率 与 《同一 个 作业 的 ) 所 有 人 








任务 。 























oa 


E 意 一 个 人 











E 务 的 平均 进度 增长 率 的 差 8 
E 何 备份 任务 。 











E 超 过 所 有 已 运行 完成 的 任务 进度 增长 率 标 ; 


任务 平均 进度 增长 率 与 所 有 正在 运行 任务 的 平均 进度 增长 率 的 最 大 允许 差距 〈 标 准 

















EAA, Wl 





方差 























E 务 运行 过 慢 ， 需 为 之 启动 一 个 备份 任务 。 其 默认 值 是 1， 表 示 如 果 一 个 任务 平均 进度 增 





(3) mapreduce. job.speculative.speculativecap 














这 个 参数 用 于 限定 该 作业 允许 启动 备份 但 
推测 执行 功能 的 任务 数 不 能 超过 了 














2. 启 动 备份 任务 











PÉ 
入 以 下 几 个 变量 : 

















口 progressRate (O) ,: 作业 J 中 所 有 运行 状态 为 s (可 以 为 做 者 r， 分别 表示 已 经 运行 完成 的 任务 和 


的 进度 增长 率 ，O 〇 为 人 
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EfEIS 4TH 








E 务 的 任务 数目 











占 正 在 运行 任务 的 百分比 。 




















介绍 对 于 一 个 作业 J 与 TaskTracker X， 如 何 ; 


E 务 的 10%。 








判断 是 否 能 够 在 X 上 为 J 的 某 个 任务 《比如 任务 T) 启动 一 个 备份 任务 。 


























F 均 进度 增长 率 的 差距 超过 所 有 任务 进度 增长 率 标 准 方差 的 1 倍 ， 则 需 为 该 任务 启动 一 个 备份 





其 默认 值 为 0.1， 表 示 可 为 一 个 作业 启动 


首先 引 

















FE 在 运行 的 任务 ) 的 任务 











F 务 集合 。 如 果 O 为 某 个 TaskTracker， 则 表示 该 TaskTracker 上 所 有 运行 状态 为 s 的 任务 平均 进度 增长 率 ， 如 果 





O 为 *， 








Qos: 作业 J 所 有 任务 进度 增长 率 的 标准 


其 中 progressT 是 当前 和 





则 表示 整个 集群 中 所 有 运行 




















状态 为 s 的 任务 


progressRate,= 




















方差 。 








F 均 进度 增长 率 。 对 于 任意 一 个 任务 T， 它 的 人 





progress, 


currentTime—dispatchTime, 





E 务 进度 增长 率 计算 方法 为 : 


E 务 执行 进度 ，currentTime 为 系统 当前 时 间 ，dispatchTimer 任务 T 被 调度 的 时 间 。 


U slowNodeThreshold/slowTaskThreshold/speculativeCap: 分 别 对 应 以 上 三 个 配置 选项 的 参数 人 








何 时 选择 并 启动 备份 任务 是 | 
fndSpeculativeTask 方 法 月 

















于 选择 









































任务 选择 策略 决定 的 ， 具 体 可 参考 6.7.2 小 节 。 在 JobTracker 端 ，JobInProgress 类 中 的 


























一 个 需 启动 备份 任务 的 Task。 它 通过 以 下 四 步 发 现 一 个 “ 拖 后 腿 ” 任 务 : 











步骤 1 判断 X 是 否 是 一 个 慢 TaskTracker， 如 果 是 ， 则 不 能 启动 任何 备份 任务 。 


为 了 判断 一 个 TaskTracker 是 























估 ， 如 果 满 足以 下 条 件 ， 
时 启动 的 备份 人 





做 


则 认为 该 




















适合 启动 备份 任务 ，Hadoop 通 过 该 TaskTracker 运 行 作业 J 的 其 他 任务 时 的 性 能 表现 对 其 进行 评 
TaskTracker 有 能 力 启动 一 个 备份 任务 : 




















progressRate(X):—progressRate(*), < 6; slowNodeThreshold 


步骤 2 检查 作业 J 已 经 启动 的 任务 数 是 否 超过 限制 。 



































E 务 数目 与 所 有 









































由 于 一 个 任务 一 旦 启动 了 备份 任务 ， 则 需要 两 倍 的 计算 资源 处 理 同样 的 数据 ， 为 了 防止 推测 执行 机 制 滥用 ，Hadoop 要 求 同 
E 在 运行 任务 的 比例 不 能 超过 speculativeCap， 即 满足 以 下 条 件 : 








speculative TaskCount/numRunningTask < speculativeCap 








步骤 3 ”筛选 出 作业 J 中 满足 以 下 条 件 的 所 有 任务 ， 并 保存 到 数组 candidates 中 。 























口 该 任务 已 运行 时 间 超 过 60 秒 。 





progres 





步骤 4 按照 运行 剩余 时 间 由 大 


当 数 组 candidates 中 有 多 个 待 选 任务 时 ，Hadoop 倾 向 于 选择 乘 


的 可 能 性 最 大 。 为 此 ，Hadoop 采 用 J 








LATE 算 法 并 不 是 完美 的 。 

















其 中 ，speculativeTaskCount 表 示 作 业 J 忆 经 启动 的 备份 任务 数目 ，numRunnineTask 表 示 作 业 J 正 在 运行 的 任务 总 数 。 
































口 该 任务 未 在 TaskTracker X 上 运行 失败 过 。 


口 该 任务 没有 其 他 正在 运行 的 备份 任务 。 








口 该 任务 已 经 出 现 ' 拖 后 腿 " 的 迹象 ， 主 要 判断 准则 是 : 





sRate(*),—progressRate; < GrX slowNodeThreshold 














到 小 对 candidates 中 的 任务 进行 排序 ， 并 选择 剩余 时 间 最 大 任务 为 其 启动 备份 任务 。 























a 





—, 
































余 时 间 最 长 的 任务 ， 因 为 这 样 的 任务 使 得 其 备份 任务 替代 自己 


















































一 个 简单 的 线性 模型 估算 一 个 任务 的 剩余 时 间 timeLeft: 





_ progressRate 
timeLeft= ———_ 
l-progress 






































在 实际 使 用 时 ， 由 于 LATEF 算 法 采用 了 静态 方式 计算 任务 的 进度 对 应 前 面 的 假设 3〉， 可 能 导致 





























口 任务 进度 和 任务 剩余 时 间 企 


性 能 仍然 比较 低下 ， 主 要 体现 在 以 下 两 个 方面 。 

















口 未 针对 任务 类 型 对 节点 分 类 : 尽管 LATE 算 法 可 通过 任务 执行 速度 识别 出 ; 











为 了 解决 这 些 问题 ， 论 文 《SAMR: A Self-adaptive MapReduce Scheduling Algorithm in Heterogneous Environment) |! E LATES#¢ 14: 












































5 算 不 准确 : 这 会 导致 部 分 正常 任务 被 误 认为 是 ' 移 后 腿 ? 任 务 ， 从 而 造成 资源 浪费 。 
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BWA, MEERI Map Task 和 Reduce Task 














=> 


LI 








上 更 细 粒 度 的 识别 。 而 实际 应 用 中 ， 























些 节 点 对 于 Map Task 而 言 是 慢 节 点 ， 但 对 Reduce Task 而 言 则 是 快 节点 。 














T% 























基础 上 进行 了 改进 ， 提 出 了 SAMR (Self Adaptive MapReduce) 算法 。 该 算法 通过 历史 信息 调整 各 个 参数 以 提高 估算 任务 进度 和 任 
务 剩 余 时 间 的 准确 性 ， 同 时 分 别针 对 Map Task 和 Reduce Task 将 节点 分 成 快 节点 和 慢 节点 。 
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6.6.4 2.0 版 本 的 算法 


Apache MapReduce 2. 0 简称 MRvV2， 也 称 为 YARN， 即 Yet Another Resource Negotiator) 属于 下 一 代 MapReduce 计 算 框 架 ， 我 
们 将 在 第 12 章 进行 详细 介绍 。MapReduce 2.0 采 用 了 不 同 于 以 上 两 种 算法 的 推测 执行 机 制 ， 它 重点 关注 新 启动 的 备份 任务 是 否 有 
潜力 比 当 前 正在 运行 的 任务 完成 得 更 早 。 如 果 通 过 一 定 的 算法 推测 某 一 时 刻 启 动 备份 任务 ， 该 备份 任务 肯定 会 比 当前 任务 完成 得 
晚 ， 那 么 启动 该 备份 任务 只 会 浪费 更 多 的 资源 。 然 而 ， 从 另 一 个 角度 看 ， 如 果 推 测 备份 任务 比 当前 任务 完成 得 早 ， 则 启动 备份 任 
务 会 加 快 数据 处 理 ， 且 备份 任务 完成 得 越 早 ， 启 动 备份 任 务 的 价值 越 大 。 

























































































































































































假设 某 一 时 刻 ， 任 务 T 的 执行 进度 为 progress， 则 可 通过 一 定 的 算法 推测 出 该 任务 的 最 终 完成 时 刻 estimatedEndTime。 男 一 方 
面 ， 如 果 此 刻 为 该 任务 启动 一 个 备份 任务 ， 则 可 推断 出 它 可 能 的 完成 的 时 刻 estimatedEndTime”， 于 是 可 得 出 以 下 几 个 公式 ; 









































Oo 














estimatedEndTime=estimatedRunTime+taskS tartTime 
estimatedRunTime= (currentTimestamp-taskStartTime) /progress 
estimatedEndTime'=currentTimestamp+averageRunTime 


其 中 ，currentTimestamp 为 当前 时 刻 ; taskStartTime 为 该 任务 启动 时 刻 ; averageRunTime 为 已 经 成 功 运 行 完成 的 任务 的 平均 运行 
时 间 。 这 样 ，MRVY2 总 是 选择 (estimatedEndTimeestimatedEndTime”〉 差 值 最 大 的 任务 ， 并 为 之 启动 备份 任务 。 为 了 防止 大 量 任 务 同 
时 启动 备份 任务 造成 资源 浪费 ，MRv2 为 每 个 作业 设置 了 同时 启动 的 备份 任务 数目 上 限 。 






















































































推测 执行 机 制 实际 上 采用 了 经 典 的 算法 优化 方法 : 以 空间 换 时 间 ， 它 同时 启动 多 个 相同 任务 处 理 相 同 的 数据 ， 并 让 这 些 任 务 
竞争 以 缩短 数据 处 理 时 间 。 显 然 ， 这 种 方法 需要 占用 更 多 的 计算 资源 。 在 集群 资源 紧缺 的 情况 下 ， 应 合理 使 用 该 机 制 ， 争 取 在 多 
少量 资 源 的 情况 下 ， 减 少 大 作业 的 计算 时 间 。 








































































































6.7 ”Hadoop 资 源 管理 
















































































Hadoop 资 源 管理 由 两 部 分 组 成 :资源 表示 模型 和 资源 分 配 模型 。 其 中 ， 资 源 表示 模型 用 于 描述 资源 的 组 织 方式 ，Hadoop 采 用 “和 情 
位 ”(slot) 组 织 各 节点 上 的 资源 ， 而 资源 分 配 模型 则 决定 如 何 将 资源 分 配给 各 个 作业 /任务 ， 在 Hadoop 中 ， 这 一 部 分 由 一 个 插 拔 式 的 调度 
器 完成 。 

















Hadoop 引 入 了 "Siotf 粮 念 表示 各 个 节点 上 的 计算 资源 。 为 了 简化 资源 管理 
切 分 成 若干 份 ， 每 一 份 用 
源 
































E，Hadoop 将 各 个 节点 上 的 资源 CPU、 内存 和 磁盘 等 等 
个 slot 表 示 ， 同 时 规定 一 个 Task 可 根据 实际 需要 占用 
象 简化 成 一 种 资源 (slot) ， 从 而 大 大 简化 了 资源 管理 问题 。 




































































多 个 slot11] 。 通 过 引入 ‘slot 这 一 概念 ，Hadoop 将 多 维 


























更 进一步 说 ，slot 相 当 于 任务 运行 “许可 证 


slot 数 目 决定 了 该 节点 上 的 最 大 人 允 放 








o 





























个 任务 只 有 得 到 该 "许可 证 ?后 ， 才 能 够 获得 运行 的 机 会 ， 这 也 意味 着 ， 每 个 节点 上 的 

F 的 任务 并 发 度 。 为 了 区 分 Map Task 和 Reduce Task 所 用 资源 量 的 差异 ，slot 又 被 分 为 Map slot 和 Reduce slot 
两 种 ， 它 们 分 别 只 能 被 Map Task 和 Reduce Task 使 用 。Hadoop 集 群 管理 员 可 根据 各 个 节点 硬件 配置 和 应 用 特点 为 它们 分 配 不 同 的 Map slot 数 
(由 参数 mapred.tasktrackermap.tasks.maximum 指 定 ) 和 Reduce slot 数 〈 由 参数 mapred.tasktrackerreduce.tasks.maximum 指 定 ) o 


在 分 布 式 计算 领域 中 ， 资 源 分 配 问题 实际 上 是 

































































me 
yH 



























































个 任务 调度 问题 。 它 的 主要 任务 是 根据 当前 集群 中 各 个 节点 上 的 资源 〈 包 括 CPU、 
内 存 和 网 络 等 资源 ) 剩余 情况 与 各 个 用 户 作业 的 服务 质量 (Quality of Service) 要求 
对 作 }| 








， 在 资源 和 作业 /人 


= 








服务 质量 的 要 求 是 多 样 化 的 ， 因 此 ， 分 布 式 系统 

















































































































任务 之 间 做 出 最 优 的 匹配 。 由 于 用 户 
的 任务 调度 是 一 个 多 目标 优化 问题 ， 更 进一步 说 ， 它 是 一 个 典型 的 NP 问 题 。 
在 Hadoop 中 ， 由 于 Map Task 和 Reduce Task 运 行 时 使 月 
































了 不 同 种 类 的 资源 〈 不 同 种 类 的 slot) ， 且 这 两 种 资源 之 间 不 能 混用 ， 因 此 任务 
周 度 器 分 别 对 Map Task 和 Reduce Task 单 独 进行 调度 。 而 对 于 同一 个 作业 而 言 ，Reduce Task 和 Map Task 之 间 存 在 数据 依赖 关系 ， 默 认 情 况 
TF, “Map Task 完 成 数目 达到 总 数 的 5% (可 通过 参数 mapred.reduce.slowstart.conpleted.maps 配 置 ) Ja, AY 






































Task 开 始 被 调度 ) 。 











于 始 





自动 Reduce Task (Reduce 





一 个 作业 从 提交 到 开始 执行 的 过 程 如 图 6-10 所 示 ， 整 个 过 程 大 约 需 7 步 


© initJob 









@ assignTasks 








D submitJob 






TaskScheduler 





Client JobTracker 





© tasks list 











TaskTracker 







TaskTracker TaskTracker 


(7) launch task 


6-10 ”作业 从 提交 到 开始 执行 的 过 程 

















步骤 1 客户 端 调用 作业 提交 函数 将 程序 提交 到 JobTracker 端 ; 














步骤 2 ”JobTracker 收 到 新 作业 后 ， 通 知 任务 调度 器 (TaskScheduler) 对 作业 进行 初始 化 ; 
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步骤 3 某 个 TaskTracker 向 JobTracker 汇 报 心 跳 ， 其 中 包含 剩余 的 Slot 数目 和 能 和 否 接收 新 任务 等 人 


Tir 





























步骤 4 ”如 果 该 TaskTracker 能 够 接收 新 任务 ， 则 JobTracker 调 用 TaskScheduler 对 外 函数 assignTasks 为 该 TaskTracker 分 配 新 任务 ; 


T 











步骤 $ TaskScheduler 按 照 一 定 的 调度 策略 为 该 TaskTracker 选 择 最 合适 的 任务 列表 ， 并 将 该 列表 返回 给 JobTracker; 








步骤 6 JobTracker 将 任务 列表 以 心跳 应 答 的 形式 返回 给 对 应 的 TaskTracker; 


步 又 7 TaskTracker 收 到 心跳 应 答 后 ， 发 现 有 需要 启动 的 新 任务 ， 则 直接 启动 该 任务 。 














本 小 节 重 点 关注 Hadoop 的 资源 分 配 模型 ， 它 由 一 个 插 拔 式 的 调度 器 TaskScheduler 实 现 。 下 一 小 节 主 要 介绍 TaskScheduler 的 架构 与 设计 
思路 。 

















6.7.1 任务 调度 框架 分 析 
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在 Hadoop 中 ， 任 务 调度 是 一 个 可 插 拔 的 模块 。 用 户 可 以 根据 自己 的 实际 应 用 需求 设计 调度 器 ， 然 后 在 配置 文件 中 指定 相应 的 调度 器 
(可 通过 参数 mapred.jobtracker.taskScheduler 配 置 ) ， 这 样 JobTracker 启 动 时 便 会 加 载 该 调度 器 。 










































































Hadoop 提 供 了 一 个 调度 器 公共 基础 类 TaskScheduler， 用 户 只 需 继承 该 类 并 根据 需要 重新 实现 其 中 的 若干 个 函数 便 可 以 实现 自己 的 调 
度 器 。TaskScheduler 类 的 主要 定义 如 下 : 























abstract class TaskScheduler implements Configurable{ 


protected TaskTrackerManager taskTrackerManager; // 实 际 就 是 JobTracker 
public synchronized void setTaskTrackerManager ( 

TaskTrackerManager taskTrackerManager) { 
this.taskTrackerManager=taskTrackerManager; 


} 

// 初 始 化 函数 
public void start()throws IOException { 
//do nothing 


} 
// 结 束 函 数 
public void terminate()throws IOException { 
//do nothing 


} 
// 为 TaskTracker 分 配 新 任务 


public abstract List<Task>assignTasks (TaskTracker taskTracker) 
throws IOException; 





















































在 Hadoop 中 ， 任 务 调度 器 和 JobTracker 之 间 存 在 函数 相互 调用 的 关系 ， 它 们 彼此 都 拥有 对 方 需要 的 信息 或 者 功能 。 对 于 JobTracker 而 
言 ， 它 需要 调用 任务 调度 器 中 的 assignTasks 函 数 为 TaskTracker 分 配 新 的 任务 ， 同 时 ，JobTracker 内 部 保存 了 整个 集群 中 的 节点 、 作 业 和 任 
务 的 运行 时 状态 信息 ， 这 信息 是 任务 调度 器 进行 调度 决策 时 需要 用 到 的 。JobTracker 与 调度 器 之 间 的 函数 调用 关系 如 图 6-11 所 示 ， 需 要 注 
意 以 下 几 点 : 





























































































































1) 任务 调度 器 需要 通过 一 个 或 者 多 个 JobInProgressListener 对 象 从 JobTracker 端 监听 作业 状态 的 变化 ， 包 括 作 业 添 加 、 作 业 更 新 和 作业 























2) 任务 调度 器 包括 两 个 主要 功能 : 作业 初始 化 和 任务 调度 。 其 中 ， 作 业 初 始 化 发 生 在 
JobInProgressListener#jobAdded (JobInProgress) 之 后 ，TaskSchedulerfassignTasks (TaskTrack er) 之 前 ， 通 过 调用 函数 
JobInProgress.initJob (JobInProgress) 完成 。 



























































mEn 





3) 任务 调度 器 中 最 重要 的 对 外 函数 是 assignTasks。JobTracker 收 到 能 够 接收 新 任务 的 TaskTracker 后 ， 会 调用 该 函数 为 它 分 配 新 任务 。 
它 的 输入 参数 是 一 个 TaskTracker 对 象 ， 输 出 参数 是 为 该 TaskTracker 分 配 的 任务 列表 。 


























XxxScheduler 
(extends TaskScheduler) 


JobTracker 


public static JobTracker startTrackeJobConf conf, 
String identifier) { public synchronized void set TaskTracker Manager ( 
TaskTracker Manager taskTrackerManager) { 
/这 于 的 tasKTrackerManager 实 际 上 就 是 
JobTracker 对 象 */ 
this .taskTracker Manager= taskTracker Manager; 


} 


result = new JobTracker(conf, identifier); 
result.taskScheduler set TaskTracker Manager 
(result); 


/位 于 JobTracker 构 造 函数 中 ， 用 于 构造 调度 轿 对 象 
taskScheduler = 

(TaskScheduler )ReflectionUtilsnewlnstance (scheduler 
Class, conf); 


/初始 化 调度 器 ， 一 般 需 配置 自己 编写 的 ] */ 
JoblnProgressListener 
public void start () { 


public void offerService() { 


taskTracker ManageraddJobInProgressListener(xxx 


/ 往 册 作业 监听 器 
public void 


! 1 

| JobClient | addJoblnProgressListener(JoblnProgressListener 

L -r-i _ | listener) { LRI. ENS JobTracker't, ikke. 一 旦 有 
| joblnProgressListenersadd (listener); } 作业 变化 【增加 /删除 /修改 》 ，JobTracker 会 立刻 通知 
1 调度 器 ]*/ 
| private class XXXListener extends 
1 SR JobInProgressListener { 
| /添加 新 作业 ， 通 过 作业 监听 器 通知 调度 器 public void jobAdded (JobInProgress job) { 

<RPC> 1 private synchronized JobStatus addJob (JobID jobld, 
| JobInProgress job) { 
submitJob() i 

1 
1 for (JobInProgressListener listener: 
jobInProgressListeners) { 
i try{ 
| listener.jobA dded (job); 
i 

人 ] 1 

| TaskTracker | ! 

1 1 


ATaskTracker 汇 报 心 跳 ，JobTracker 为 之 分 配 任务 
public synchronized HeartbeatResponse heartbeaf … ) 


/最 和 要 的 函数 ”给 定 一 个 TaskTracker 信 息 ， 返 回 分 
配给 它 的 任务 列表 ]*/ 

public synchronized List <Task> 

assignTasks (TaskTracker tracken{ 


taskScheduler .assignTasks(taskTrackersget(trackerNa 











图 6-11 JobTracker 与 调度 器 之 间 的 函数 调用 关系 














Hadoop 以 队列 为 单位 管理 作业 和 资源 ， 每 个 队列 分 配 有 一 定量 的 资源 ， 同 时 管理 员 可 指定 每 个 队列 中 资源 的 使 用 者 以 防止 资源 滥 
和 。 添 加 “队列 "这 一 概念 后 ， 现 有 的 Hadoop 调 度 器 本 质 上 均 采 用 了 三 级 调度 模型 。 如 图 6-12 所 示 ， 当 一 个 TaskTracker 出 现 空闲 资源 时 ， 
调度 器 会 依次 选择 一 个 队列 、《 选 中 队列 中 的 )》 作业 和 《选中 作业 中 的 ) 任务 ， 并 最 终 将 这 个 任务 分 配给 TaskTracker。 
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a task 
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A task 
to launch 





图 6-12 三 级 调度 模型 


(DD 选择 一 个 队列 书 选 择 一 个 作业 @®) 选 择 一 个 任务 














在 Hadoop 中 ， 不 同 任务 调度 器 的 主要 区 别 在 于 队列 选择 策略 和 作业 选择 策略 不 同 ， 而 任务 选择 策略 通常 是 相同 的 ， 也 就 是 说 ， 给 定 














一 个 节点 ， 从 一 个 作业 中 选择 一 个 任务 需 考虑 的 因素 是 一 样 的 ， 均 主要 为 数据 本 地 性 (data-localty) 。 总 之 ， 一 个 任务 调度 器 通用 的 
assignTasks 函 数 伪 代码 实现 如 下 : 




















// 为 TaskTracker 分 配 任务 ， 
List<Task>assignTasks 
List<Task>taskList; 


并 返回 任务 列表 


(TaskTracker taskTracker) : 








while taskTracker.askForTasks(): // 不 断 分 配 新 的 任务 

Queue queue=selectAQueueFromCluster(); // 从 系统 中 选择 一 个 队列 
JobInProgress job=selectAJobFromQueue (queue) ; // 从 队列 中 选择 一 个 作业 
Task task=job.obtainNewTask (job) ; // 从 作业 中 选择 一 个 任务 


taskList.add (task) ; 
taskTracker.addNewTask 
return taskList; 











(task) ; 





























于 不 同调 度 器 采用 的 人 























E 务 选择 策略 是 一 样 的 ， 因 此 Hadoop 将 之 封装 成 一 个 通用 的 模块 供 各 个 调度 器 使 用 ， 具 体 存放 在 JobInProgress 




















类 中 的 obtainNewMapTask 和 obtainNewReduceTask 方 法 中 。 我 们 将 在 下 一 小 节 分 析 这 两 个 方法 的 实现 机 制 。 






































[1] 一 个 Task 可 使 用 多 少 slot 完 全 由 调度 器 决定 。 当 前 大 部 分 调度 器 只 支持 一 个 Task 占 用 一 个 slot， 比 如 FIFO 和 Fair Scheduler， 而 Capacity 











Scheduler 则 可 根据 Task 内 存 需 





求 为 其 分 配 多 个 slot。 


6.7.2 ”任务 选择 策略 分 析 








任务 选择 发 生 在 调度 器 选 定 一 个 作业 之 后 ， 目 的 是 从 该 作业 中 选择 一 个 最 合适 的 任务 。 在 Hadoop 中 ， 选 择 Map Task 时 需 考 虑 的 最 习 


要 的 因素 是 数据 本 地 性 ， 也 就 是 尽量 将 任务 调度 到 数据 所 在 节点 。 除 了 数据 本 地 性 之 外 ， 还 需 考虑 失败 任务 、 备 份 任务 的 调度 顺序 等 。 
然而 ， 
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H F Reduce Task 没 有 数据 本 地 性 可 言 ， 因 此 选择 Reduce Task 时 通常 只 需 考 虑 未 运行 任务 和 备份 任务 的 调度 顺序 。 





(1) 数据 本 地 性 


























在 分 布 式 环境 中 ， 为 了 减少 任务 执行 过 程 中 的 网 络 传输 开销 ， 通 常 将 任务 调度 到 输入 数据 所 在 的 计算 节点 ， 也 就 是 让 数据 在 本 地 进 
行 计算 ， 而 Hadoop 正 是 以 “尽力 而 为 "的 策略 保证 数据 本 地 性 的 。 






































为 了 实现 数据 本 地 性 ，Hadoop 需 要 管理 员 提供 集群 的 网 络 拓扑 结构 。 如 图 6-13 所 示 ，Hadoop 集 群 采 用 了 三 层 网 络 拓扑 结构 ， 其 中 ， 
根 节 点 表示 整个 集群 ， 第 一 层 代 表 数 据 中 心 ， 第 二 层 代 表 机 架 或 者 交换 机 ， 第 三 层 代 表 实 际 用 于 计算 和 存储 的 物理 节点 。 对 于 目前 的 
Hadoop 各 个 版 本 而 言 ， 默 认 均 采用 了 二 层 网 络 拓扑 结构 ， 即 数据 中 心 一 层 暂时 未 被 考虑 。 















































bl bl b2 bl b2 b3 
b8 b2 b4 b3 b4 b7 b7 b6 b8 b8 
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图 6-13 Hadoop 网 络 拓扑 结构 图 


Hadoop 根 据 输入 数据 与 实际 分 配 的 计算 资源 之 间 的 距离 将 任务 分 成 三 类 : node-local GA A 








届 与 计算 资源 同 节 点 ) ，rack-local (E) 
LAŁ) 和 o 储 switch〈 跨 机 架 ) 。 当 输入 数据 与 计算 资源 位 于 不 同 节点 上 时 ，Hadoop 需 将 输入 数据 远程 复制 到 计算 资源 所 在 节点 进行 处 
里 。 两 者 距离 越 远 ， 需 要 的 网 络 开 销 越 大 ， 因 此 调度 器 进行 任务 分 配 时 尽量 选择 离 输入 数据 近 的 节点 资源 。 
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当 Hadoop 进 行 任务 选择 时 ， 采 用 了 自 下 向 上 查找 的 策略 。 由 于 当前 采用 了 两 层 网 络 拓扑 结构 ， 因 此 这 种 选择 机 制 决定 了 任务 优先 级 
从 高 到 低 依次 为 : node-local、rack-local 和 o 企 switch。 下 面 结合 图 6-13 介 绍 三 种 类 型 的 任务 被 选中 的 场景 。 















































假设 某 一 时 刻 ，TaskTracker X 出 现 空闲 的 计算 资源 ， 向 JobTracker 汇 报 心跳 请 求 新 的 任务 ， 
务 Y。 








en 


四 度 器 根据 一 定 的 调度 策略 为 之 选择 了 任 








场景 1 如 果 X 是 HL， 任 务 Y 输 入 数据 块 为 b1， 则 该 任务 为 node-local。 


场景 2 如 果 X 是 H1， 任 务 Y 输 入 数据 块 为 D2， 则 该 任务 为 rack-local。 








场景 3 ”如 果 X 是 HI1， 任 务 Y 输 入 数据 块 为 4， 则 该 任务 为 oswitch。 








(2) Map Task 选 择 策略 

















— 





户 追 踪 作 业 运 行 状态 的 JobInProgress 对 象 为 Map Task 维 护 了 五 个 数据 结构 : 














//Node 与 未 运行 的 TIP 集 合 映射 关系 ， 通 过 作业 的 InputFormat 可 
Map<Node, List<TaskInProgress>>nonRunningMapCac 
//Node 与 运行 的 TIP 集 合 映射 关系 ， 一 个 任务 获得 调度 机 会 ， 其 TIP 
Map<Node, Set<TaskInProgress>~>runningMapCache; 
//non-local 且 未 运行 的 TIP 集 合 ，non-local 是 指 任 
能 是 一 些 计算 密集 型 任务 ， 比 如 Hadoop exmaple 中 的 PI 作业 
final List<TaskInProgress>nonLocalMaps; 
// 按 照 Task Attempt 失 败 次 数 排序 的 TIP 集 合 

final SortedSet<TaskInProgress>failedMaps; 
//non-local 且 正在 运行 的 TIP 集 合 


Set<TaskInProgress>nonLocalRunningMaps; 








































































































接 获 取 的 
& 














务 没 有 输入 数据 〈InputSp1lit 为 空 ) // 


这 可 













































































当 需 要 从 作业 中 选择 一 个 Map Task 时 ， 调 度 器 会 直接 调用 JobInProgress 中 的 obtain-NewMapTask 方 法 。 该 方法 封装 了 所 有 调度 器 公用 的 
任务 选择 策略 实现 。 其 主要 思想 是 优先 选择 运行 失败 的 任务 ， 以 让 其 快速 获取 重新 运行 的 机 会 ， 其 次 是 按照 数据 本 地 性 策略 选择 尚未 运 
行 的 任务 ， 最 后 是 查找 正在 运行 的 任务 ， 尝 试 为 " 竹 后 腿 "任务 启动 备份 任务 。 具 体 步 又 如 下 ， 
































检查 。 如 果 一 个 作业 在 某 个 节点 上 失败 任 








步骤 1 性 
任务 分 配给 该 节点 。 


合法 






























































务 数目 超过 一 定 阔 值 或 者 该 节点 剩 










































































余 磁 盘 容 量 不 足 ， 则 不 再 将 该 作业 的 任何 


度 的 机 


步 又 2 ”从 failedMaps 列 表 中 选择 任务 。failedMaps 保 存 了 按照 Task Attempt 失 败 次 数 排序 的 TIP 集 合 。 失 败 次 数 越 多 的 任务 ， 被 调 
会 越 大 。 需 要 注意 的 是 ， 为 了 让 失败 的 任务 快速 得 到 重新 运行 的 机 会 ， 在 进行 任务 选择 时 不 再 考虑 数据 本 地 性 。 
步骤 3 ”从 nonRunningMapCache 列 表 中 选择 任务 。 采 用 的 任务 选择 方法 完全 遵循 数据 本 地 性 策略 ， 即 任务 选择 优先 级 从 高 到 低 依次 为 





LES » 





node-local, rack-local 和 o 企 Switch 类 型 











步骤 4 从 nonLocalMaps 列 表 中 选择 任务 。 由 于 nonLocalMaps 中 的 人 








HES ”从 runningMapCache 列 表 中 选择 任务 。 遍 历 runningMapCache 列 表 ， 查 找 是 否 存在 1 


动 一 个 备份 任务 。 





步骤 6 ”从 nonLocalRunningMaps 列 表 中 选择 任务 。 同 步 又 5， 从 nonLocalRunningMaps 列 表 中 查找 ' 拖 后 腿 ” 任 务 ， 





ESCA HA Bu 















































步骤 2 一 6 中 任何 一 个 步骤 中 查找 到 一 个 合适 的 任务 后 则 








直接 返 




















Hl, AN 

















(3) Reduce Task 选 择 策略 














> 











于 Reduce Task 不 存在 数据 本 地 性 ， 因 此 ， 与 Map Task 相 比 ， 


























#4J: nonRunningReduces 和 runningReduces， 分 别 表示 尚未 运行 的 TIP 列 表征 








HHL Av 








性 检 





步骤 2 ”从 nonRunningReduces 列 表 中 选择 任务 。 无 须 考虑 数 ] 
对 应 节点 上 失败 过 ) 的 任务 。 








E 务 ， 为 “ 拖 后 腿 " 的 任务 








步骤 3 ”从 runningReduces 列 表 中 选择 和 





AH 


进行 Fo 























它 的 调 


度 策 略 显得 非常 简单 。 








E 在 运行 的 TIP 列 表 。 由 此 采用 的 人 各 


查 。 同 Map Task 一 样 ， 对 节点 可 靠 性 和 磁盘 空间 进行 检查 。 




















Es ZN 需 依次 遍历 该 列表 中 








启动 备份 人 


E 务 。 








i 的 步骤。 
























































JobInProgress 对 象 为 其 保存 了 两 个 数 扩 
F 务 选择 步骤 如 下 ; 





的 任务 ， 选 出 第 一 个 满足 条 件 〈 未 














居 ， 因 此 无 须 考虑 数据 本 地 性 。 
ET AHR AVES, MRA, MARA 
为 其 启动 备份 任务 。 


a 





6.7.3 FIFO 调 度 器 分 析 


























当前 Hadoop 自 带 了 多 个 任务 调度 器 ， 最 常用 的 是 FIFO〈 默 认 调度 器 ) ~ Capacity Scheduler 和 Fair Scheduler 三 种 。 在 本 小 节 中 ， 我 
们 重点 介绍 FIFO 调 度 器 ， 其 他 两 种 将 在 第 10 章 介绍 。 















































FIFO， 顾 名 思 义 ， 即 首先 到 达 的 作业 优先 获得 调度 机 会 。 它 是 由 类 org.apache.hadoop.mapred.JobQueueTaskScheduler 实 现 的 
关系 如 图 6-14 所 示 。 
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-conf : JobConf 

-taskTrackerManager : TaskTrackerManager 

+getConf() : Configuration 

+setConf(in conf : Configuration) 

+setTaskTrackerManagein taskTrackerManager: TaskTrackerManager) 







+assignTasks(in taskTracker: TaskTracker) : List<Task> 


+getJobs(in queueName : String) : Collection<JobInProgress> 
+refresh() 


JobQueueJobInProgressListener 






JobInProgressListener 


+jobAdded(in job : JobInProgress) 
+jobRemoved(in job : JobInProgress) 


> 


tjobUpdated(in event : JobChangeE vent ) 


Al 6-14 FIFO 类 关系 图 








JobQueueTaskScheduler 同 时 向 JobTracker 注 册 了 两 种 作业 监听 器 ， 功 能 如 下 。 























口 EagerTaskInitializationListener 对 用 户 提 交 的 作业 进行 初始 化 ， 考 虑 到 待 初始 化 的 作业 可 能 非常 多 ， 因 此 需 采 用 一 定 的 策略 决定 新 
提交 作业 的 初始 化 顺序 ， 基 本 策略 是 优先 选择 优先 级 高 的 作业 ， 当 优先 级 相同 时 ， 优 先 选 择 提交 时 间 早 的 作业 。 
































口 JobQueueJobInProgressListener 维 护 作 业 的 调度 顺序 : 该 作业 监听 器 维护 了 作业 被 调度 的 顺序 ， 其 排序 原则 跟 初 始 化 顺序 类 似 ; 
先 按 作 业 优 先 级 排序 ， 然 后 是 作业 提交 时 间 ， 最 后 是 作业 ID。 








基于 以 上 两 种 作业 监听 器 ，JobQueueTaskScheduler 的 调度 机 币 
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(由 函数 assignTasks 实 现 ) 如 下 。 









































口 计算 可 用 slo 钱 目 : FIFO 调 度 器 尽量 将 所 有 任务 均衡 地 调度 到 各 个 TaskTracker， 以 便 均 衡 地 使 用 各 个 节点 上 的 资源 。 对 于 


TaskTracker X， 假 设 它 的 slot 总 数 为 tackerCapacity， 当 前 正在 运行 的 任务 数 为 tackerRunnineTasks， 则 可 通过 以 下 方法 计算 它 当 前 可 使 
用 的 slot 数 目 : 















































loadFactor —min | Room 一 i 


johs 


availableSlots = [loadFactorxtrackerCapacity |-tracke rRunning Tasks 








口 分 配 任务 : 遍历 作业 队列 “《 





己 按照 








周 度 顺序 排 好 序 ) ， 并 依次 调 月 


其 中 ，numiTasks 和 finishedTasks 表 示 作 业 总 的 任务 数 和 已 经 完成 的 任务 数 ，totalSlots 表 示 系 统 的 slot 总 数 。 











obtainNewReduceTask 为 该 TaskTracker 选 择 availableSlots 个 任务 。 








H JobInProgressž 4 


的 obtainNewMapTask 和 


6.7.4 ”Hadoop 资 源 管理 优化 




















前 面 提 到 ，Hadoop 资 源 管理 | 





两 部 分 组 成 : 资源 表示 模型 和 资源 分 配 模型 。 考 虑 到 这 两 部 分 是 耦合 在 一 起 的 ， 因 上 出 
时 进行 优化 ， 则 需要 同时 结合 这 两 部 分 进行 考虑 。 本 小 节 介绍 了 三 种 常见 的 Hadoop 资 源 管 型 
:于 无 类 别 slot 的 方案 和 基于 真实 资源 需求 量 的 方案 。 














bo WREX Hadoop 
E 优 化 方案 、 分 别 为 基于 动态 slot 的 方 












































在 正式 介绍 这 几 个 资源 优化 方案 之 前 ， 我 们 先 回顾 一 下 Hadoop 1.0 中 的 资源 管理 方案 。Hadoop 1.0 采 用 了 基于 slot 的 资源 表示 模型 。 为 
了 简化 资源 分 配 问题 ，Hadoop 将 各 个 节点 上 的 多 维度 资源 〈CPU、 内 存 、 网 络 JO 和 磁盘 IO 等 ) 抽象 成 一 维度 slot， 这 样 便 把 复杂 的 多 维度 
资源 分 配 问题 转换 成 简单 的 slot 分 配 问题 。 此 外 ， 考 虑 到 Map Task 和 Reduce Task 资 源 使 / 




































































量 不 同 ，Hadoop 又 进一步 将 Slot 划分 成 Map slot 和 




















Reduce slot 两 种 ， 并 规定 Map Task 只 能 使 用 Map slot, Reduce Task 只 能 使 用 Reduce slot。 具 体 如 图 6-15 所 示 。 


JobTracker 














6-15 ”基于 slot 的 资源 管理 方案 

















(1) 基于 动态 slot 的 资源 管理 方案 























Hadoop 1. 0 中 的 资源 分 配方 案 采 用 了 静态 资源 设置 策略 ， 即 每 个 节点 实现 配置 好 可 


























的 slot 总 数 ， 这 些 slot 数 目 一 旦 启动 后 无 法 再 动态 
了 较 大 差异 ， 静 态 配置 so 数目 往 















































修改 。 考 虑 到 实际 应 用 场景 中 ， 不 同 作 业 对 资源 的 需求 往往 
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主 会 导致 节点 上 的 资源 利用 率 过 高 或 者 过 











低 。 为 了 解决 该 问题 ， 可 尝试 采用 动态 调整 slot 数 目 














的 方案 由 ， 具 体 如 图 6-16 所 示 。 该 方案 在 每 个 节点 上 安装 一 个 slo 坝 目 动态 调整 模块 
SlotsAdjuster， 它 可 以 根据 节点 上 的 资源 利用 率 动 态 调整 sot 数 目 ， 以 便 更 合理 地 利用 资源 。 
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© Used slot 


个 Added slot 
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Deleted slot 
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TaskTracker TaskTracker TaskTracker 





6-16 ”基于 动态 slot 的 资源 管理 方案 




















(2) 基于 无 类 别 slot 的 资源 管理 方案 












































对 于 一 个 MapReduce 应 用 程序 而 言 ，Map Task 优 先 得 到 调度 ， 而 只 有 当 Map Task 完 成 数目 达到 一 定 比 例 〈 默 认 是 5%) Ja, Reduce Task 
才 开 始 获得 调度 机 会 。 因 此 ， 从 单个 应 用 程序 看 ， 刚 开始 运行 时 ，Map slot 资 源 紧缺 而 Reduce sot M, Map Task 全 部 运行 完成 



































后 ，Reduce slot 紧 缺 而 Map slot 空 闲 。 很 明显 ， 这 种 区 分 Slot 类别 的 资源 管理 方案 在 一 定 程度 上 降低 了 slot 的 利用 率 。 如 图 6-17 所 示 ， 一 种 直 




















观 的 解决 方案 是 不 再 区 分 Map slot 和 Reduce slot!?!, ， 而 是 只 有 一 种 slot， 并 详 
Map Task 和 Reduce Task， 则 完全 由 调度 器 决定 。 





FMap Task 和 Reduce Task 共 享 这 些 slot， 至 于 怎样 将 这 些 slot 分 配给 

















JobTracker 





TaskTracker TaskTracker TaskTracker 




















图 6-17 基于 无 类 别 slot 的 资源 管理 方案 




















(3) 基于 真实 资源 需求 量 的 资源 管理 方案 



































让 我 们 进一步 分 析 这 种 基于 无 类 别 slot 的 资源 管理 方案 可 能 存在 的 问题 。 由 于 整个 Hadoop 集 群 中 只 有 一 种 slot， 因 此 ， 这 隐 含 着 各 个 
TaskTracker 上 的 slot 是 同 质 的 ， 也 就 是 说 ， 一 个 slot 实 际 上 代表 了 相同 的 资源 。 然 而 ， 在 实际 应 用 环境 中 ,用户 应 用 程序 对 资源 需求 人 
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多 样 化 的 〈 不 同 应 用 程序 对 资源 的 要 求 不 同 ) 。 这 种 基于 无 类 别 slot 的 资源 划分 方法 的 划分 粒度 仍 过 于 粗糙 ， 往 往 会 造成 节点 资源 利用 率 
过 高 或 者 过 低 中 。 比 如 ， 管 理 员 事先 规划 好 一 个 slot 代 表 2 GB 内 存 和 1 个 CPU， 如 果 一 个 应 用 程序 的 任务 只 需要 1 GB 内 存 ， 则 会 产生 资源 
碎片 ” 从 而 降低 集群 资源 的 利用 率 ， 同 样 ， 如 果 一 个 应 用 程序 的 任务 需要 3 GB 内 存 ， 则 会 隐 式 地 抢占 其 他 任务 的 资源 ， 从 而 产生 资源 抢 
占 现 象 ， 可 能 导致 集群 利用 率 过 高 。 因 此 ， 寻 求 一 种 更 精细 的 资源 划分 方法 显得 尤为 必要 。 













































































































































































让 我 们 回归 到 资源 分 配 的 本 质 ， 即 根据 任务 资源 需求 为 其 分 配 系统 中 的 各 类 资源 。 在 实际 系统 中 ， 资 源 本 身 是 多 维度 的 ， 包 括 CPU、 
内 存 、 网 络 JO 和 磁盘 IO 等 ， 因 此 。 如 果 想 精确 控制 资源 分 配 ， 不 能 再 有 slot 的 概念 ， 最 直接 的 方法 是 让 任务 直接 向 调度 器 申请 自己 需要 的 
资源 (比如 某 个 任务 可 申请 1.5 GB 内 存 和 1 个 CPU) ， 而 调度 器 则 按照 任务 实际 需求 为 其 精细 地 分 配对 应 的 资源 量 ， 不 再 简单 地 将 一 个 Slot 
分 配给 它 ， 有 具体 如 图 6-18 所 示 。 
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TaskTracker TaskTracker TaskTracker 

















图 6-18 基于 真实 资源 需求 量 的 资源 管理 方案 





























Hadoop 2.0 中 便 采 用 了 这 种 完全 基于 真实 资源 需求 量 的 资源 管理 方案 ， 比 如 Apache YARN. Facebook Corona 等 〈 将 在 第 12 章 详细 介 
绍 ) 。 相 比 于 基于 slot 的 方案 ， 这 种 方案 更 加 直观 ， 且 能 够 大 大 提高 资源 利用 率 。 
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6.8 小结 


本 章 介绍 了 Hadoop MapReduce 最 核 


JobTracker 是 整个 MapReduce 计 算 框 


























心 的 服务 JobTracker 的 实现 。 





架 中 的 主 服务 ， 相 当 于 集群 世 
























































围绕 这 两 个 方面 讲解 JobTracker。 

JobTracker 启 动 过 程 涉 及 三 个 方 重要 对 象 初始 化 、 了 
各 个 TaskTracker 的 心跳 请 求 。 

JobTracker 的 主要 功能 之 一 是 作业 控 




















出 ， 包 括 作业 的 分 解 和 状态 监控 。 


者 ”， 负 责 整个 集 和 








= 
其 中 ， 取 
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的 作业 控制 和 资源 管理 。 
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[ 作 线 程 初始 化 和 作业 恢复 。 启 动 之 后 ， 将 开启 RPC server 以 等 待 来 自 


的 是 状态 监控 ， 包 括 TaskTracker 状 态 监 


控 、 作 业 状 态 监控 和 任务 状态 监控 ， 其 中 ， 作 业 状 态 监 控 采 用 了 “三 层 多 叉 树 " 烧 型 ， 该 模型 分 为 三 层 ， 从 高 到 低 依次 为 





JobInProgress、TaskInProgress 和 Task Attempt 三 种 对 象 集合 。 

















状态 监控 的 一 个 目的 是 容错 ，Hadoop 设 计 了 各 个 级 别 的 容错 机 抽 


括 JobTracker 容 错 、TaskTracker 容 错 、Job/Task 容 错 、Record 容 错 和 磁盘 容错 等 。 
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JobTracker 另 外 一 个 功能 是 资源 管理 
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而 资源 分 配 模型 实际 上 是 任务 调度 


TaskTracker 出 现 空闲 资源 时 ， 调 度 器 会 

















模型 ， 





已 | 











依次 选择 一 个 队列 、 














分 配给 TaskTracker。 本 章 以 Hadoop 默 认 





HJ FIFO BE Jyly 








可 揪 拔 的 任务 调度 器 完 
《选中 队列 中 的 ) 作业 和 《选中 
解 了 一 个 简单 调度 器 的 实现 原理 。 

















成 。 当 前 大 部 分 调 
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部 分 组 成 : 资源 表示 模型 和 资源 分 配 模型 。Hadoop 采 用 了 基于 slot 的 资源 表示 模 
度 器 采用 了 三 级 调度 架构 ， 即 当 一 个 
作业 中 的 ) 任务 ， 并 最 终 将 这 个 任务 








第 7 章 TaskTrackerW ah Sci all ir 





在 Hadoop 中 ，MapReduce 采 用 了 masterslave 架 构 。 这 在 第 6 章 已 提 到 了 ， 并 对 与 master 对 应 的 JobTracker 进 行 了 详细 介绍 。 在 本 
章 中 ， 我 们 将 剖析 slave 的 实现 一 TaskTacker。 与 JobTracker 一 样 ，TaskTracker 也 是 以 服务 组 件 的 形式 存在 的 。 它 分 布 在 各 个 slave 
节点 上 ， 负 责任 务 的 执行 和 任务 状态 的 汇报 。 









































本 章 将 从 TaskTracker 架 构 、TaskTracker 行 为 《如 启动 新 任务 ， 杀 和 死 任 务 等 ) 、 作 业 目 录 管 理 和 任务 启动 等 几 个 方面 深入 分 析 
TaskTracker 工 作 原理 及 其 实现 。 


























7.1 ”TaskTracker 概 述 

















TaskTracker 是 Hadoop 集 群 中 运行 于 各 个 节点 上 的 服务 。 它 扮演 着 “通信 枢纽 "的 角色 ， 是 JobTracker 与 Task 之 间 的 沟通 桥梁 
一 方面 ， 它 从 JobTracker 端 接收 并 执行 各 种 命令 ， 比 如 运行 任务 、 提 交 任 务 、 杀 死 任务 等 ， 另 一 方面 ， 它 将 本 节点 上 的 各 个 任务 
状态 通过 周期 性 心跳 汇报 给 JobTracker， 具 体 如 图 7-1 所 示 。 
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send heartbeat HeartbeatResponse RPC 


[LaunchTaskAction [CommitTaskAction | {KillTaskAction] [KillJobAction] [TaskTrackerReinitAction 


ee | TaskTracker TaskMemory Manager 
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图 7-1 TaskTracker 工 作 原 理 图 























TaskTracker 与 JobTracker 和 Task 之 间 采 用 了 RPC 协 议 进行 通信 。 对 于 TaskTracker 和 JobTracker 而 言 ， 它 们 之 间 采 用 
InterTrackerProtocol 协 议 ， 其 中 ，JobTracker 扮 演 RPC Server 的 角色 ， 而 TaskTracker 扮 演 RPC Client 的 角色 ; 对 于 TaskTracker 与 Task 而 
言 ， 它 们 之 间 采 用 TaskUnbilicalProtocol 协 议 ， 其 中 ，TaskTracker 扮 演 RPC Server 的 角色 ， 而 Task 扮 演 RPC Client 的 角色 。 这 两 个 协 
议 的 具体 内 容 已 在 第 4 章 进行 了 详细 介绍 ， 本 章 不 再 重复 介绍 。 













































































总 体 来 说 ，TaskTracker 实 现 了 两 个 功能 : 汇报 心跳 和 执行 命令 。 具 体 如 下 : 


C1) 汇报 心跳 



































TaskTracker 周 期 性 地 将 所 在 节点 [上 各 种 信息 通过 心跳 机 制 汇报 给 JobTracker。 这 些 信息 包括 两 部 分 ， 机 器 级 别 信息 ， 如 节 
点 健康 状况 、 资 源 使 用 情况 等 ， 任 务 级 别 信息 ， 如 任务 执行 进度 、 任 务 运行 状态 、 任 务 Counter 值 等 。 




































































(2) 执行 命令 























JobTracker 收 到 TaskTracker 心 跳 信 息 后 ， 会 根据 心跳 信息 和 当前 作业 运行 情况 为 该 TaskTracker 下 达 命令 ， 主 要 包括 启动 任务 
(LaunchTaskAction) 、 提 交 任 务 〈CommitTaskAction) 、 杀 死 任务 〈KilTaskAction) ~ JEA (KiWobAction 和 重新 初始 化 
(TaskTrackerReinitAction) 5 种 命令 。 其 中 ， 过 程 比较 复杂 的 是 启动 任务 。 为 了 防止 任务 之 间 的 干扰 ，TaskTracker 为 每 个 任务 创建 

一 个 单独 的 Java 虚 拟 机 (Java Virtual Machine, JVM) ， 并 有 专门 的 线程 监控 其 资源 使 用 情况 ， 一 旦 发 现 超 量 使 用 资源 就 直接 将 其 


杀 掉 。 
































































































































区 别 它们 ， 但 通常 情况 下 只 部 署 个 。 














Ja 


























[1] Hadoop 人 允许 一 个 节点 上 部 署 多 个 TaskTracker， 并 通过 端 


7.2 ”TaskTracker 启 动 过 程 分 析 














TaskTracker 服 务 由 TaskTracker 类 实现 。 该 类 实现 了 四 个 接 
TaskTrackerMXBean。 其 中 ，MRConstants 定 义 了 一 些 常量 ; 
Runnable 是 Java 库 中 的 线程 接口 ， 实 现 该 接口 意味 着 将 以 线程 用 
MXBean， 方 便 外 界 监控 工具 (比如 Ganglia、Nagios 等 ) 4) 



























































， 分 别 是 MRConstants, TaskUmbilicalProtocol, Runnable 和 






































TaskUmbilicalProtocol 定 义 了 TaskTracker 与 Task 之 间 的 RPC 协 议 ; 
式 启 动 TaskTracker;，TaskTrackerMXBean 实 现 了 一 个 JMX 
取 TaskTracker 运 行 时 的 信息 。 


TaskTracker 是 一 个 独立 的 服务 ， 有 一 个 对 应 的 main 函 数 启动 它 。main 函 数 实现 非常 简单 : 创建 一 个 TaskTracker 对 象 并 启动 








public class TaskTracker implements MRConstants, TaskUmbilicalProtocol, 


Runnable, TaskTrackerMxBean { 
dee // 成 员 变量 定义 和 成 员 函 数 实现 
public static void main (String argv[]) throws 








Exception { 


TaskTracker tt=new TaskTracker (conf) ; // 创 建 TaskTracker 对 象 

















tt.run(); // 启 动 TaskTracker 线 程 





eans.register ("TaskTracker", "TaskTrackerInfo", tt) ; // 注 册 MxBean 
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TaskTrackerft ME PRP) Sa EE 
JobTracker 发 送 心 跳 并 领取 新 的 任务 。 
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接 下 来 将 展开 介绍 TaskTracker 的 启动 过 程 ， 包 括 重要 变量 初始 化 、 





对 象 和 线 和 








7.2.1 重要 变量 初始 化 





























TaskTracker 类 中 包含 很 多 成 员 变 由 
个 非常 重要 的 变量 的 含义 。 











TU 
+ 
i 
4 


























Limi 
ro 
ya 

出 














ey 而 在 rur 方 法 中 维护 一 个 与 JobTracker 的 通信 连接 ， 


对 象 初始 化 等 。 


以 周期 怕 





地 向 











于 管理 节点 和 监控 节点 上 的 任务 。TaskTracker 启 动 时 会 初始 化 这 些 变量 。 下 面 介 绍 几 














volatile boolean running=true; //TaskTracker 是 否 正 在 运行 


InterTrackerProtocol jobClient; //RPC Client, 
short heartbeatResponseld=-1; // 心 跳 响 应 ID 








TaskTrackerStatus status=null; //TaskTracker 状 态 信息 
HashMap<TaskAttemptID, 
对 应 关系 


Map<TaskAttemptID, TaskInProgress>tasks=new 
TaskInProgress>(); // 该 节点 上 TaskAttemptID 与 TIP 









































于 与 JobTracker 通 信 








Map<TaskAttemptID, TaskInProgress>runningTasks=null; /* 该 节点 上 正在 运行 的 


TaskAttemptID 与 TIP 对 应 关系 */ 





// 该 节点 正 运 行 的 作业 列表 。 如 果 一 个 作业 中 的 任务 在 节点 上 运行 ， 则 折 














Map<JobID, RunningJob>runningJobs=new TreeMap<JobI 
次 汇报 心 


boolean acceptNewTasks=true; // 是 否 接受 新 任务 ， 每 








private int maxMapSlots; //TaskTracker 上 配置 的 Map slo 








private int maxReduceSlots; //TaskTracker 上 配置 的 Reduc 





private volatile int heartbeatInterval=HEARTBI 


EAT IN’ 





巴 该 作业 加 入 该 数据 结构 
D, RunningJob> (); 
eee 























e Slot 数目 
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ERVAL MI 














告诉 JobTracker 


; // 心 跳 间隔 





7.2.2 ”重要 对 象 初始 化 





TaskTracker 构 造 函数 内 部 对 一 些 重 要 对 象 进行 了 初始 化 ， 具 体 可 见 表 7-1。 


表 7-1 TaskTracker 需 初始 化 的 对 象 列 表 


对 象 名 对 应 类 名 意义 解释 
aclsManager ACLsManager 作业 访问 权限 控制 
server HttpServer 将 TaskTracker 相关 信息 显示 到 Web 前 端 
taskController TaskController 用 于 控制 任务 的 初始 化 ， 终 结 和 清理 工作 
userLogManager UserLogManager 用 户 日 志 管 理 
jvmManager JvmManager JVM 管理 


taskReportServer Server RPC Server, Task 通过 RPC [a] i% Server 汇报 进度 
distributedCacheManager | TrackerDistributedCacheManager 分 布 式 缓存 管理 

jobClient InterTrackerProtocol RPC Client, TaskTracker 通过 该 Client [a] JobTracker 
汇报 心跳 

mapEventsFetcher MapEventsFetcherThread 获取 已 运行 完成 的 Map Task 列表 ， 为 Reduce 
Task 远程 拷贝 数据 做 准备 


( 续 ) 
对 象 名 对 应 类 名 意义 解释 
task Memory Manager TaskMemory ManagerThread 任务 内 存 监 控 


taskLauncher 启动 任务 

localizer 任务 本 地 化 ， 即 准备 任务 运行 环境 
healthChecker 节点 健康 状况 检查 

jettyBugMonitor 应 对 Jetty 中 存在 的 bug 临时 启用 的 一 个 监控 线程 


我 们 将 在 后 面 几 节 中 介绍 表 中 这 些 类 的 具体 实现 。 














7.2.3 ”连接 JobTracker 








前 面 几 章 中 提 到 TaskTracker 与 JobTracker 之 间 通 过 心跳 机 制 通信 。TaskTracker 服 务 初次 启动 后 ， 会 向 JobTracker 发 出 第 一 个 心 
跳 信息 ， 经 过 JobTracker 一 系列 安全 检查 后 ， 将 被 添加 到 Hadoop 集 群 中 ， 进 而 被 分 配 各 种 任务 。 我 们 将 在 下 一 节 中 详细 介绍 心跳 
HLI o 
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7.3 心跳 机 制 


7.3.1 单 次 心跳 发 送 








第 6 章 中 已 经 提 到 ，JobTracker 与 TaskTracker 之 间 采 用 了 pul 通 信 模 型 ， 即 JobTracker 从 不 会 主动 与 TaskTracker 通 信 ， 而 总 是 被 
动 等 待 TaskTracker 汇 报信 息 并 领取 其 对 应 的 命令 。TaskTracker 周 期 性 地 向 JobTracker 汇 报信 息 并 领取 任务 形成 心跳 。 



































在 TaskTracker 类 的 rur 方 法 中 维护 了 一 个 无 限 循环 ， 用 于 通过 心跳 发 送 状 态 信息 和 接收 命令 ， 代 码 框架 如 下 : 




















public void run() { 


State osState=offerService(); 





其 中 ，offerService 函 数 代码 框架 如 下 : 





State offerService()throws Exception{ 

while (running& &! shuttingDown) { 

// 判 断 是 否 到 达 心 跳 发 送 时 间 

// 发 送 心跳 

HeartbeatResponse heartbeatResponse=transmitHeartBeat (now) ; 
// 执 行 心跳 响应 heartbeatResponse 中 的 各 种 命令 
markUnresponsiveTasks () ，// 杀 死 一 定时 间 内 未 汇报 进度 的 任务 

killoverflowingTasks (); // 剩 余 磁 盘 空 间 小 于 mapred.local.dqir.minspacekil1 时 ， 寻 找 合 
适 的 任务 将 其 杀 掉 以 释放 空间 
































TaskTracker 的 单 次 心跳 发 送 过 程 如 图 7-2 所 示 ， 可 分 为 以 下 几 个 步骤 。 











BA DE 
送 时 间 ? 


Yes 


TaskTracker 刚 启 
动 ? 


TaskTracker 与 
JobTracker 编 译 版 本 
是 否 一 致 ? 





是 否 有 正常 磁盘 出 
现 故 障 ? 








返回 DENIED 状 态 









返回 STALE 状态 









执行 其 他 命令 






ReinitTrackerAction 


返回 NORMAL 状态 





图 7-2 TaskTracker 单 次 心跳 发 送 过 程 


步骤 1 判断 是 否 到 达 心 跳 发 送 时 间 。 


TaskTracker 的 心跳 间隔 ! 














1) 集群 规模 : JobTracker 能 
放 到 TaskTracker 的 本 次 心跳 应 答 中 。 





2) 任务 运行 情况 : 为 了 提高 任 
























































即 缩短 心跳 间隔 ， 以 便 将 任务 完成 或 失败 的 消息 

















运行 情况 共同 决定 。 

















前 集群 规模 (TaskTracker 数 量 ) 动态 调整 TaskTracker 的 心跳 间隔 ， 并 将 下 一 次 心跳 间隔 

















跳 ”。TaskTracker 包 含 以 下 





其 














个 配置 参数 设置 











DQ mapreduce. tasktracker.outofband.heartbeat: 决定 


Q mapreduce. tasktracker.outofband.heartbeat.damper 


H, heartbeatInterval: M JobTrackeriii 











是 否 启用 带 外 心跳 机 制 

















获取 的 心跳 间隔 ;oobHeartbeatDamper 是 心跳 收缩 


(mapreduce.tasktracker.outofband. heartbeat.damperxt ) ff {HL 





步骤 2 如果 TaskTracker 刚 启动 ， 则 需要 检查 代码 编译 版 本 与 JobTracker 是 




















只 有 与 JobTracker 



































订 版 本 号 、 代 码 编译 























3dlab0b947ac39”, H 
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MapReduce 计 算 过 程 中 最 重要 的 输出 
应 一 个 磁盘 块 ) 。! 


步骤 3 ”检查 是 否 有 磁盘 损坏 。 





















































查 mapred.local dx 指定 的 磁盘 目录 列表 ， 并 将 正 沸 








和 .0.0-dev 表 示 Hadoop 版 本 号 ，“451451 家 示 修 订 版 本 号 ，“dongxicheng 表示 代 码 编 译 月 
S4b3 佑 cb07ealcd833dlab0b947ac39: 表 示 校 验 和 

















。 默 认 值 是 全 se， 表示 不 启用 。 


: 心跳 收缩 因子 。 默 认 值 是 1 000 000 
有 XX 个 任务 运行 完成 ， 则 心跳 间隔 变 为 heartbeatInterval (X*oobHeartbeatDamper+] ) 





才 间 和 资源 利用 率 ，TaskTracker 一 旦 发 现存 在 某 个 任务 运行 完成 或 者 失败 ， 就 会 立 
告诉 JobTracker， 进 而 快速 重新 


分 配 任务 ， 我 们 将 这 种 特殊 的 心跳 称 为 "' 带 外 心 
DANT 

















Ne 





。 妆 启用 带 外 心跳 机 制 时 ， 如 果 某 时 刻 











>H 
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录 是 参数 mapred.localdir 指 定 的 中 间 结 果 存 放 目 录 C 
于 这 些 目 录 存 放 在 本 地 磁盘 且 没 有 备份 ， 因 此 一 





























台 化 。 


步骤 4 发 送 心跳 。 





TaskTracker 将 当前 节点 运行 时 信息 


JobTracker 的 各 种 命令 


AT o 








步骤 5 ”接收 并 执行 站 











比如 资源 使 用 情况 、 任 务 运行 状态 等 ， 通 过 心跳 汇报 给 JobTracker， 同 时 接收 来 E 








JobTracker 收 到 TaskTracker 的 心跳 信息 





接 下 来 我 们 重点 分 析 发 送 心跳 和 命令 执行 




















和 正常 目录 存放 起 来 ， 之 后 ，TaskTracker 周 期 性 
mapred.disk.healthChecker.interval 指 定 ， 默 认 是 60 s) 检查 这 些 ] 














吾 ， 会 为 之 下 达 命 令 





vay Ae 


译 版 本 号 的 TaskTracker 才 能 够 向 JobTracker 发 送 心跳 。 代 码 编译 版 本 号 由 Hadoop 版 本 号 、 修 
户 和 校 验 和 四 部 分 组 成 ， 如 和].0.0-dev ftom 451451 by dongxicheng source checksum e54b3f6cb07ealcd83 








媚 编 译 用 














二 是 


日 损坏 或 者 丢失 后 ， a 





Si 
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由 多 个 目录 组 成 ， 每 个 目录 对 
所 计算 。TaskTracker 初 始 化 时 会 检 














二 间 间隔 


些 正 常 目录 ， 如 果 发 现 出 现 故 障 的 目录 ， 则 TaskTracker 


























会 重新 对 自己 初 


























7.3.2 ”状态 发 送 









































TaskTracker 通 过 心跳 向 JobTracker 汇 报 的 是 当前 节点 运行 时 信息 ， 包 括 TaskTracker 基 本 信息 、 











点 资源 使 用 情况 和 各 个 任务 





状态 等 ， 这 些 信息 被 封装 到 可 序列 化 类 TaskTrackerStatus 中 。 每 次 发 送 心 跳 时 ，TaskTracker 会 根据 最 新 信息 重新 构造 一 个 





TaskTrackerStatus， 且 每 次 包含 的 信息 量 可 能 不 一 样 。 比 如 ， 任 务 的 计数 器 信息 每 隔 60 s 才 会 发 送 
为 tue 时 ， 才 会 发 送 节点 资源 使 用 信息 。 其 中 ，askForNewTask 值 的 计算 方法 如 下 : 
































次 ， 且 只 有 当 askForNewTask 





askForNewTask= 

C Cstatus.countOccupiedMapSlots () <maxMapSlots|| 
status .countOccupiedReduceSlots () <maxReduceSlots) && 
acceptNewTasks) ; // 存 在 空闲 的 Map slot 或 者 Reduce slot， 且 磁盘 剩余 空间 大 于 
mapred.local.dir.minspacekill 


T 











TaskTrackerStatus 包 含 的 基本 信息 如 下 : 





String trackerName; //TaskTracker 名 称 
String host; //TaskTracker 主 机 名 

int httpPort; //TaskTracker 对 外 的 HTTP 端 口号 
int failures; //TaskTracker 上 已 经 失败 任务 总 数 
List<TaskStatus>taskReports: // 当 前 TaskTracker 上 各 个 任务 运行 状态 
volatile long lastSeen; // 上 次 汇报 心跳 的 时 间 
private int maxMapTasks; //Map slot 总 数 ， 即 允许 同时 运行 的 Map Task 总 数 ， 由 参数 mapred. 
tasktracker.map.tasks.maximum 设 定 
private int maxReduceTasks; //Reduce slot 总 数 ， 即 允许 同时 运行 的 Reduce Task 总 数 ， 由 参 
数 mapred.tasktracker.reduce.tasks.maximum 设 定 

private TaskTrackerHealthStatus healthStatus; //TaskTracker 健 康 状态 

private ResourceStatus resStatus; //TaskTracker 资 源 (内 存 ，CPU 等 ) 信息 





















































下 面 重点 介绍 taskReport、healthStatus 和 resStatus 三 个 变量 值 的 意义 及 其 计算 方法 。 

















1.taskReport 

















taskReport 保 存 当 前 TaskTracker 上 所 有 任务 (实际 为 Task Attempt) 的 运行 状态 ， 每 个 任务 保存 信息 如 下 : 





public abstract class TaskStatus implements Writable, Cloneable 
private final TaskAttemptID taskid; //Task Attempt ID 

private float progress; // 任 务 执行 进度 ， 范 围 为 0.0 一 1.0 

private volatile State runState; /* 任 务 运行 状态 ， 包 括 RUNNING, SUCCEEDED, FAILED, 
UNASSIGNED, KILLED, COMMIT PENDING, FAILED UNC LEAN, KILLED UNCLEAN*/ 
private String diagnosticInfo; / /诊断 信息 ， TREY 吓 信息 和 运行 异常 信息 

private String stateString; // 字 符 串 形式 的 运行 状态 
private String taskTracker; // 该 TaskTracker 名 称 ， 可 唯一 表示 一 个 TaskTracker， 形 式 如 
tracker mymachine: 50010 
private int numSlots; // 运 行 该 Task Attempt 需 要 的 slot 数 目 ， 默 认 值 是 1 
private long startTime; //Task Attempt 开 始 时间 
private long finishTime; //Task Attempt 完 成 时 间 
private long outputSize=-1L; //Task Attempt 输 出 数据 量 

private volatile Phase phase=Phase.STARTING; // 任 务 运 行 阶段 ， 包 括 STARTING，MRAP， 
SHUFFLE, SORT, REDUCE, CLEANUP 
ae Counters counters; // 该 任务 中 定义 的 所 有 计数 器 〈 包 括 系 统 自 带 计数 器 和 用 户 自 定义 计数 
at PA AH) 

private boolean includeCounters; // 是 否 包 含 计 数 器 ， 计 数 器 信息 每 隔 60 s 发 送 一 次 

// 下 一 个 要 处 理 的 数据 区 间 ， 用 于 定位 坏 记 录 所 在 区 间 


private SortedRanges.Range nextRecordRange=new SortedRanges.Range(); 







































































































































































2. healthStatus 
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healthStatus 保 存 了 当前 节点 健康 状况 ， £X} M TaskTrackerHealthStatus2k, 7 LaF: 





static class TaskTrackerHealthStatus implements Writable{ 
private boolean isNodeHealthy; // 节 点 是 否 健 月 
private String healthReport; // 如 果 节 点 不 健康 ， 则 记录 导致 不 健康 的 原因 
private long lastReported; // 上 次 汇报 健康 状况 的 时 间 





ot 
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标准 输 昌 








healthStatus 是 由 NodeHealthCheckerService 线 程 中 计算 得 到 的 。 该 线程 允许 管理 员 配 置 一 个 “健康 监测 脚本 ”以 检查 节点 健康 ; 
日 管理 员 可 在 该 脚本 中 添加 任何 检查 语句 作为 节点 是 否 健康 运行 的 依据 。 如 果 脚 本 检测 到 该 节点 处 于 不 健康 状态 ， 它 需要 
中 打印 一 条 以 字符 串 “ERROR” 开 头 的 输出 语句 。NodeHealthCheckerService 线 程 周 期 性 调用 健康 监测 脚本 并 检查 其 输出 ， 
一 旦 发 现 脚本 输出 是 以 “ERROR” 开 头 的 字符 串 ， 则 认为 节点 处 于 不 健康 状态 ， 进 而 将 其 标注 为 “unhealthy 并 通过 心跳 告诉 
JobTracker， 而 JobTracker 得 知 节点 状态 变 为 “unhealthy* 后 ， 会 将 其 加 入 黑 名 单 ， 此 后 不 再 为 它 分 配 新 任务 。 需 要 注意 的 是 ， 只 要 
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TaskTracker 服 务 是 活着 的 ， 该 线程 会 一 直 运 行 该 脚本 ， 一 旦 发 现 节点 又 变 为 "healthy” JobTracker 会 立刻 将 其 从 黑 名单 中 移 除 ， 从 


而 又 会 为 之 分 配 任 务 。 通 过 引入 该 机 币 





ayy 
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， 可 带 来 很 多 好 处 。 














口 可 作为 节点 负载 的 反馈 : 比如 ， 可 让 健康 检测 脚本 检查 网 络 、 磁 盘 、 文 件 系统 等 运行 状况 ， 一 旦 发 现 特殊 情况 ， 比 如 网 络 
拥塞 、 磁 盘 空 间 不 足 或 者 文件 系统 出 现 问题 ， 可 将 健康 状况 变 为 "anhealkhy”， 和 暂时 不 接收 新 的 任务 ， 待 它们 恢复 正常 后 再 继续 接 
收 新 任务 。 

































































口 人 为 暂时 维护 TaskTracker: 如 果 发 现 TaskTracker 所 在 节点 出 现 故 障 ， 可 通过 控制 脚本 输出 暂时 让 该 TaskTracker 停 止 接收 新 























任务 以 便 进 行 维护 ， 待 维护 完成 后 ， 修 改 脚 本 输出 以 让 TaskTracker 继 续 接收 新 任务 。 












































NodeHealhCheckerService 线 程 包含 四 个 可 配置 参数 ， 有 具体 如 表 7-2 所 示 。 用 户 可 根据 需要 在 mapred-site.xml 文 件 中 配置 这 些 参 














表 7-2 NodeHealthCheckerService 线程 配置 参数 
参数 名 称 参数 含义 
mapred.healthChecker.script.path 健康 检测 脚本 所 在 的 绝对 路 径 ， 线 程 NodeHealthCheckerService 会 周期 
性 执行 该 脚本 以 判断 节点 健康 状况 ， 如 果 该 值 为 室 ， 则 不 会 启动 该 线程 
mapred.healthChecker.interval 健康 监测 脚本 调用 频率 (单位 ， 毫秒 ) 


mapred.healthChecker.script.timeout | 如果 健康 监测 脚本 在 一 定时 间 内 没有 响应 ， 则 线程 NodeHealthCheckerService 
会 将 节点 标注 为 “unhealthy” 


mapred.healthChecker.script.args 监控 脚本 的 输入 参数 ， 如 果 有 多 个 参数 ， 则 用 逗号 隔 开 











下 面 给 出 一 个 健康 监测 脚本 实例 。 在 这 个 Shel 脚 本 中 ， 当 一 个 节点 上 的 空闲 内 存量 低 于 总 内 存量 的 10% 时 ， 将 打印 





























以 ERROR” 开 头 的 字符 串 ， 这 样 ， 该 节点 将 不 再 向 JobTracker 请 求 新 任务 。 














#! /bin/bash 

MORY RATIO=0.1 

freeMem=grep MemFree/proc/meminfolawk' {print$2}"' 

totalMem=grep MemTotal/proc/meminfo|awk' {print$2}"' 
limitMem=echo|awk'{print int ("'StotalMem'"*"'SMEMORY RATIO'") } 

if [S$freeMem-1tSlimitMem]; then E 

echo"ERROR, totalMem=$totalMem, freeMem=$freeMem, limitMem=$limitMem" 
else 

echo"OK, totalMem=$totalMem, freeMem=$freeMem, limitMem=$limitMem" 

fa 

















3.resStatus 











resStatus 保 存 了 当前 TaskTracker 资 源 使 用 情况 。 该 变量 对 应 ResourceStatus 类 ， 定 义 如 下 : 





static class ResourceStatus implements Writable{ 
private long totalVirtualMemory; // 总 的 可 用 虚拟 内 存量 ， 单 位 为 byte 
private long totalPhysicalMemory; // 总 的 可 用 物理 内 存量 
private long mapSlotMemorySizeOnTT; // 每 个 Map slot 对 应 的 内 存量 
private long reduceSlotMemorySizeOnTT; // 每 个 Reduce slot 对 应 的 内 存量 
private long availableSpace; // 可 用 磁盘 空间 

Es // 可 用 的 虚拟 内 存量 



















































































private long availableVirtualMemory=UNAVAILABLI 
private long availablePhysicalMemory=UNAVAILABLE; // 可 用 的 物理 内 存量 
private int numProcessors=UNAVAILABLE; // 节 点 总 的 处 理 器 个 数 
private long cumulativeCpuTime=UNAVAILABLE; // 运 行 以 来 累计 的 CPU 使 用 时 间 
private long cpuFrequency=UNAVAILABLE; //CPU 主 频 ， 单 位 为 kHz 

























































































private float cpuUsage=UNAVAILABLE; //CPU 使 用 率 ， 单 位 为 % 























resStatus 是 由 可 插 拔 组 件 ResourceCalculatorPlugn( 抽 象 类 ) 获取 的 ， 当 前 只 存在 Linux 版 本 实现 的 LinuxResourceCalculatorPlugin 


中 ， 其 他 操作 系统 尚未 实现 ， 这 意味 着 只 有 在 Linux 下 才 可 以 获取 资源 使 用 信息 。 此 外 ，Hadoop 也 允许 用 户 自己 编写 
ResourceCalculatorPlugin 实 现 ， 且 用 户 只 需 通 过 参数 mapreduce.tasktracker.resourcecalculatorplugin 指 定 该 类 即 可 启用 它 。 



































































































































Ph，proc 虚 拟 文件 系统 中 包含 了 一 些 目录 和 文件 ， 它 们 向 用 户 动态 呈现 了 内 核 中 的 一 些 实时 信 
目录 下 的 meminfp 、cpuinfp 和 stat 三 个 文件 获 





我 们 都 知道 ， 在 Linux 操 作 系统 9 
息 ， 比 如 进程 运行 时 的 资源 使 用 信息 。LinuxResourceCalculatorPlugin 类 正 是 通过 读 取 /proc 


sy? 


取 节 点 上 的 内 存 、CPU 等 资源 的 实时 使 用 情况 的 。 


















































[1] https//ssues. apache.org/jira/browse/MAPREDUCE-211 


7.3.3 ”命令 执行 


tecoveredJobs， 它 是 上 次 关闭 JobTracker 时 正在 运行 的 作业 集合 ， 重 启 JobTracker 后 需 恢 复 这 些 作 业 的 运行 状态 〈 前 提 是 用 户 启 上 


JobTracker 将 心跳 应 答 封 装 到 一 个 HeartbeatResponse 对 象 中 。 该 对 象 主要 包括 两 部 分 内 容 : 第 一 部 分 是 作业 集合 










































































了 作业 恢复 功能 ， 有 具体 参考 第 6 章 ) ， 而 TaskTracker 收 到 该 作业 集合 后 ， 需 重 置 这 些 作 业 对 应 Reduce Task 的 FetchStatus 信 息 ， 从 而 


迫使 这 些 Reduce Task 重 新 从 Map Task 端 找 贝 数据 ， 另 一 部 分 是 需要 执行 的 命令 列表 ， 相 关 代 码 如 下 。 


入 
































TaskTrackerAction[]actions=heartbeatResponse.getActions (); 
if (reinitTaskTracker (actions) ) {// 重 新 初始 化 
return State.STALE; 

} 

if (actions! =null) { 

for (TaskTrackerAction action: actions) { 

if (action instanceof LaunchTaskAction) {// 启 动 新 任务 
addToTaskQueue ( (LaunchTaskAction) action) ; 

else if (action instanceof CommitTaskAction) {// 提 交 任 务 
CommitTaskAction commitAction= (CommitTaskAction) action; 

if (! commitResponses.contains (commitAction.getTaskID()) ) { 
commitResponses.add (commitAction.getTaskID()) ; 


}else{// 杀 死 任务 或 者 作业 
tasksToCleanup.put (action) ; 
} 


} 




















(KillTaskAction) 、 杀 死 作 业 (KilJobAction) 和 重新 初始 化 (ReinitTrackerAction) 。 我 们 将 在 下 一 节 中 介绍 各 个 命令 的 处 理 ; 








TaskTracker 需 要 处 理 5 种 命令 ; 启动 新 任务 (LaunchTaskAction) 、 提 交 任 务 (CommitTaskAction) 、 杀 死 任务 
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7.4 TaskTracker 行 为 分 析 


TaskTracker 通 过 心跳 机 制 从 JobTracker 端 获 






































1 


























王 务 ， 也 可 能 由 于 任务 超 量 使 用 内 存 ， 由 框架 直 
































7.4.1 ”启动 新 任务 








TaskTracker 出 现 空闲 资源 后 ， 会 通过 心跳 从 JobTracker% 











行 状态 ， 直 到 它 运行 成 功 。 新 任务 启动 过 程 如 图 7-3 所 示 。 























TaskScheduler 


assignTasks() 





TaskList 




















1) TaskTracker 出 现 空闲 资源 ， 将 资源 使 用 








2) JobTracker 收 到 信息 后 ， 解 析 心 跳 信 息 ， 发 现 TaskTracker 上 有 空 


TaskTracker 分 配 任务 ; 





3) JobTracker 将 新 分 配 的 任务 封装 成 一 个 或 多 个 LaunchTaskAction 对 象 ， 将 其 添加 到 心跳 应 答 中 返 





4) TaskTracker 收 到 心跳 后 ， 解 析出 LaunchTaskAction 对 象 ， 














5) 当 Counter 值 或 者 进度 发 生变 化 时 ， 任 务 








JobTracker 


前 索取 任务 ， 























取 各 种 命令 ， 包 括 启 动 新 任务 、 提 交 任 务 、 杀 死 任 务 、 杀 死 作 业 
等 。 在 Hadoop 中 ， 存 在 多 种 场景 使 得 JobTracker 下 达 这 些 命令 。 比 如 ， 对 于 ' 霖 死 任 务 ? 偷 令 而 言 ， 可 能 是 人 为 通关 








接 将 其 杀 死 。 在 本 节 中 ， 我 们 为 每 个 命令 选取 一 种 场景 来 i 





























HE] 











其 执行 


新 初始 化 
Shel 命 令 杀 死 
全 过 程 。 





并 按照 一 定 步骤 启动 该 任务 ， 之 后 一 直 监 控 并 汇报 3 





TaskTracker 


! heartbeat 


LaunchTaskAction 





X 





7-3 新 任 








heartbeat 


务 启动 序列 图 








情况 通过 心跳 汇 提 








民 给 JobTracker; 





首创 建 JVM 启 动人 


























6) TaskTracker 通 过 心跳 将 任务 的 最 新 Counter 值 和 进度 汇报 给 








我 们 将 在 7.5 节 详细 剖析 TaskTracker 启 动 新 人 








E 务 的 整个 过 程 。 











A JobTracker. 


runChild() 


i statusUpdate() i 





E 务 ; 





通过 RPC 函 数 将 最 新 Counter 值 和 进度 汇报 给 TaskTracker; 





回 给 TaskTracker; 


闲 的 资源 ， 则 调用 调度 器 模块 的 assignTasks0 函 数 为 该 


(Ri 


7.4.2 ”提交 任务 








任务 提交 过 程 是 指 任务 处 理 完 数据 后 ， 将 最 终 
JIHDFS 上 的 任务 才 会 经 历 该 过 程 。 


















































前 面 提 到 Hadoop 的 推测 执行 机 制 ， Hadoop 人 允许 多 个 任务 




















为 最 终结 果 。 为 了 防止 多 个 任务 产生 相同 的 处 理 结 























务 提交 结果 后 ， 其 计算 结果 便 会 作为 最 终结 果 ， 




















Hadoop 任 务 提交 过 程 采 
































计算 结果 从 临时 目 











录 转 移 到 最 终 目 
在 Hadoop 中 ， 有 两 种 这 样 的 任务 : Reduce Task 和 map-only 类 型 作业 的 Map Task. 








果 而 造成 元 余 ， 

















的 决定 权 ， 而 其 他 参与 者 各 自负 责 在 其 本 地 执行 写 


操作 ， 











分 成 两 个 阶段 。 


第 一 阶段 《准备 阶段 ) : 各 个 参与 者 执行 完 自己 的 操作 后 ， 将 状态 变 为 “可 以 提交 ”， 














理 完 后 ， 先 向 JobTracker 发 送 结果 提交 请 求 ， 得 到 JobTracker 准 许 后 ， 才 可 以 将 结果 从 临时 目 
其 他 任务 的 计算 结果 将 被 丢弃 。 


录 的 过 程 。 





同时 处 理 同一 份 数据 ， 但 只 会 选择 最 先 运行 完成 的 任务 处 
每 个 任务 暂时 将 自己 的 计算 结果 放 到 一 个 临时 








只 有 将 输出 结果 























时 结果 作 
目录 中 ， 一 旦 处 





























录 转 移 到 最 终 








目录 中 ， 而 一 旦 一 个 任 

















采用 的 协议 。 它 把 分 布 式 事务 的 某 一 个 代理 指定 为 协调 者 ， 所 有 其 他 代理 称 为 参与 者 ， 同 时 规定 


























了 两 阶段 提交 协议 (two-phase commit protocol, 2PC) 实现 。 两 阶段 提交 协议 是 分 布 式 事务 中 经 常 
只 有 协调 者 才 有 提交 或 撤销 事务 
并 向 协调 者 提出 撤销 或 提交 子 事务 的 意向 。 两 阶段 提交 协议 把 事务 提交 


并 向 协调 者 发 送 “ 锥 备 提交 ”请 求 。 








第 二 阶段 (提交 阶段 ，: 协调 者 按照 一 定 原则 决定 是 否 允 许 参与 者 提交 ， 如 果 允 许 ， 则 向 参与 者 发 出 "确认 提交 ?请求 ， 参 与 


者 收 到 请 求 后 ， 把 “可 以 提交 ”状态 改 为 提交 完成 "状态 ， 然 后 返 
收 到 该 请 求 后 ， 把 “可 以 提交 ”状态 改 为 "提交 失败 ”状态 ， 然 后 退出 。 














对 于 MapReduce 而 言 ，JobTracker 扮 演 协 调 者 的 


协议 实现 如 图 7-4 所 示 。 








JobTracker 


heartbeat 





CommitTaskAction 


heartbeat 


任务 提交 序列 

















1) Task Attempt 处 理 完 最 后 





2) TaskTracker 得 知 一 个 Task Attempt 状 态 为 COMMIT PENDING 后 ， 立 刻 缩短 心跳 间隔 ， 以 便 快速 将 牧 


Kids CN Bey 
RUNNING 变 为 COMMIT PENDING， 并 通过 RPC 将 该 状态 和 人 牧 


























TaskTracker 
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9 色 ， 而 各 个 TaskTracker 











commitPending ( 


上 的 任务 是 参与 者 。 





回应 答 ， 如 果 不 允 许 ， 则 向 参与 者 发 送 “ 提 交 失败 请求， 参与 者 





任务 提交 过 程 对 应 的 两 阶段 提交 








Ea 
) i 





canCommit () 


canCommit () 


canCommit () 


commitResponses .add() 


canCommit () 


done () 














图 7-4 
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昌 写 在 临时 目录 ${mapred.outputdiry/ temporary/ $ftaskid} F) ， 运 行 状态 由 
E 务 提交 请 求 发 送 给 TaskTracker; 




















E 务 状态 汇报 给 





JobTracker; 
息 后 ， 检 查 它 是 否 为 某 个 TaskImnProgress 中 第 一 个 状态 变 为 COMMIT 如 果 
E 许 该 任务 提交 最 终结 果 ; 














3) JobTracker 收 到 心跳 信 ， 
是 ， 则 批准 它 进 行 任务 提交 ， 





即 在 心跳 应 答 中 添加 CommitTaskAction 命 令 ， 以 通知 TaskTracker 准 


后 ， 将 对 应 任务 加 入 可 提交 任务 列表 commitResponses 中 ; 











性 到 CommitTaskAction 命 令 


已 位 于 列表 commitResponses 中 后 ， 
FP， 并 告诉 TaskTracker 任 务 提交 完成 ; 


COMMIT PENDING 变 为 SUCCEEDED， 























4) TaskTracker! 














录 转 移 到 最 终 目 录 




















进行 结果 提交 ， 即 将 数据 从 临时 














Ce 
































5) Task Attempt 通 过 RPC 检 测 至 
(参数 $ {mapred.output.df} 对 应 的 


6) TaskTracker 得 知 任务 提交 完成 后 ， 将 该 任务 运行 状态 




















x) H 

















并 在 下 次 心跳 中 将 该 任务 









































状态 汇报 给 JobTracker。 
t 余 各 步骤 对 应 2PC 的 第 二 阶段 。 








面 第 1 步 对 应 ?PC 的 第 一 阶段 ， 而 其 


























并 结合 2PC 的 定义 ， 很 容易 知道 : 上 

















综合 以 上 几 个 步骤 ， 


7.4.3 RIMES 


Hadoop F FEZ HA RKM 





























ESA, 











它们 涉及 的 过 程 基本 相同 ， 均 是 通过 JobTracker 向 TaskTracker 发 送 KilTaskAction 命 























令 完 成 的 。 本 小 节 分 析 用 户 使 用 Shel 命 令 杀 死 任务 的 整个 过 程 ， 具 体 如 图 7-5 所 示 。 




















JobTracker TaskTracker 


! KillTask() 




















1) JobTracker 收 到 来 自 JobClient 的 杀 死 任务 请 求 后 ， 将 该 任务 添加 到 待 杀 死 任务 列表 tasksToKil 中 。 





1 heartbeat 





KillTaskAction 


TaskStatus:KILLED_ UNCLEAN 


LaunchTaskAction 





TaskStatus:SUCCEEDED 








图 7-5 杀 死 任务 序列 











j 户 输入 ‘bin/hadoop job-kill-task<task-attempt-id>"Ja, JobClienth #4] I RPC #cKillTask7 SE i%Task Attempt， 整 个 过 程 如 


a 











2) 之 后 某 个 时 刻 ，Task Attempt 所 在 的 TaskTracker 向 JobTracker 发 送 心跳 ，JobTracker 收 到 心跳 后 ， 将 该 任务 封装 到 
KilTaskAction 命 令 中 ， 并 通过 心跳 应 答 发 送 给 TaskTracker。 























3) TaskTracker 收 到 KK 训 TaskAction 命 令 








务 状 态 迅 速 通 过 带 外 心跳 告诉 JobTracker。 




















后 ， 将 该 任务 从 作业 列表 runningJobs 中 清除 ， 并 将 运行 状态 从 RUNNING 转 化 为 
KILLED UNCLEAN， 同 时 通知 directoryCleanupThread 线 程 清理 其 工作 目录 ， 释 放 所 占 模 位， 最 后 缩短 心跳 时 间 间 隔 ， 以 便 将 该 任 










































































4) JobTracker 收 到 状态 为 KILLED UNCLEAN 的 Task Attempt 后 ， 将 其 类 型 改 为 task-cleanup task《〈 这 种 任务 的 输入 数据 为 空 














但 ID 与 被 杀 Task Attempt 的 ID 相同 ， 





其 目的 是 清 












































mapCleanupTasks/reduceCleanupTasks'¥ , 


Task Tracker. 



































HEY AS Task Attempt 已 经 写 入 HDFS 的 临时 数据 ) ， 并 添加 到 待 清理 任务 队列 


























在 接 下 来 的 某 个 TaskTracker 的 心跳 中 ，JobTracker 将 其 封装 到 LaunchTaskAction 中 发 送 给 


T 

















5) TaskTracker 收 到 LaunchTaskAction 后 ， 启 动 JVM (或 重用 已 启动 的 JVM) 执行 该 任务 。 由 于 该 任务 属于 task-cleanup task, 
此 它 只 需 清理 被 杀 死 的 Task Attempt 已 写 入 HDEFS 的 临时 数据 《如 果 没 有 则 直接 跳 过 ) ， 之 后 其 运行 状态 变 为 SUCCEEDED， 并 由 
TaskTracker 通 过 下 一 次 心跳 告诉 JobTracker。 
























































T 

















6) JobTracker 收 到 运行 状态 为 SUCCEEDED 的 Task Attenmpt 后 ， 首 先 检查 它 是 否 位 于 任务 列表 tasksToK 记 中 ， 显 然 该 任务 在 该 
列表 中 ， 这 表明 它 已 经 被 杀 死 ， 于 是 将 其 状态 转化 为 KILLED， 同 时 修改 相应 的 各 个 数据 结构 。 


















































从 上 面 整 个 过 程 可 以 看 出 ，JobClient 向 JobTracker 发 出 "Kiltaslke 请 求 后 ，JobTracker 不 会 返回 任何 确认 消息 。 这 主要 是 由 于 杀 死 
王 务 的 过 程 比较 复杂 ， 要 经 历 多 个 心跳 时 间 ，JobClient 需 等 待 很 长 时 间 才 可 能 知道 任务 是 否 被 成 功 杀 死 。 
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744 杀 死 作 














杀 死 作业 是 通过 JobTracker 向 TaskTracker 发 送 KilTaskAction 命 令 完成 的 。 它 是 Hadoop 最 常见 的 行为 之 一 ， 比 如 ， 任 何 一 个 作 
业 成 功 运行 完成 后 ，JobTracker 会 向 各 个 TaskTracker 广 播 KilJobAction 以 清空 各 个 节点 上 该 作业 的 工作 目录 。 此 外 ， 用 户 可 以 通过 
调用 Shell 命 令 “binm/hadoop job-kil<job-i>” 泽 死 一 个 作业 。 本 小 节 主 要 分 析 用 户 使 用 Shelt 命 令 杀 死 作业 的 过 程 ， 具 体 如 图 7-6 所 


JobTracker TaskTrackerl TaskTracke2 


' KillJob() ! 





























































































































1 heartbeat 









LaunchTaskActionKillTaskAction 


TaskStatus: SUCCEEDED 





KillJobAction 





图 7-6 杀 死 作业 序列 图 











用 户 输入 一 条 ' 色 死 任务 ”的 Shell 偷 令 后 ，JobClent 通 过 RPC 函 数 Kilob 向 JobTracker 发 送 杀 死 作业 请 求 。JobTracker 收 到 请 求 
后 ， 涉 及 的 过 程 如 下 : 














1) 作业 的 JobInProgress 对 象 将 jobKiled 变 量 置 为 tue， 并 杀 死 该 作业 所 有 的 job-setup task, map task 和 reduce task CEE: job- 
cleanup task 保 留 ) 。 














2) 此 后 假设 TaskTrackerl 第 一 个 向 JobTracker 汇 报 心跳 ， 则 JobTracker 将 该 作业 的 job-cleanup task 封 装 成 LaunchTaskAction 命 
令 ， 将 该 TaskTracker 对 应 的 已 被 杀 任 务 封装 成 KiTaskAction 命 令 ， 并 把 这 些 命令 添加 到 心跳 应 答 中 返回 给 TaskTracker1 。 

















3) 对 于 接 下 来 发 送 心跳 的 TaskTracker, JobTracker 将 对 应 的 被 杀 死 任务 封装 成 KilTaskAction 命 令 ， 并 把 这 些 命 令 添 加 到 心跳 应 
答 中 返回 给 这 些 TaskTracker。 


4) TaskTrackerl 收 到 来 自 JobTracker 的 命令 后 ， 执 行 相应 的 操作 : 若 为 KTaskAction 命 令 ， 则 进行 的 操作 与 举 死 任务 ”中 的 第 
3 步 类 似 ， 执 行 完 命令 后 ， 将 作业 状态 KILLED UNCLEAN 汇 报 给 JobTracker;， 若 为 LaunchTaskAction 命 令 ，TaskTracker 将 创建 JVM 
执行 该 任务 ， 但 由 于 该 任务 没有 需要 处 理 的 数据 ， 因 此 很 快 可 以 运行 完成 ， 任 务 完成 后 ， 其 状态 转化 为 SUCCEEDED， 并 


TaskTracker 通 过 心跳 告诉 JobTracker。 




































































5) 其 他 TaskTracker 收 到 JobTracker 端 的 KWTaskAction 命 令 后 ， 进 行 与 第 4 步 类 似 的 操作 。 

















6) JobTracker 收 到 TaskTracker 汇 报 的 心跳 后 ， 若 心跳 信息 包含 
JÉ (jobKilled=true) ， 则 将 任务 由 KILLED_UNCLEAN 状 态 转化 为 KILLED 状 态 ， 若 心跳 信息 包含 job-cleanup task 运 行 成 功 〈 状 态 为 























SUCCEEDED) ， 则 向 各 个 TaskTracker 广 抬 












































$A RASAE KILLED UNCLEAN， 由 于 任务 所 属 作业 已 被 杀 





KK 训 obAction 命 令 ， 以 清 ] 


理 作 业 的 了 


CVE 



































录 和 相关 的 内 存 结构 〈 比 如 runningJobs) 。 


7.4.5 重新 初始 化 








如 果 TaskTracker 上 某 个 磁盘 出 现 故 障 或 者 TaskTracker 收 到 来 自 JobTracker 的 ReinitTrackerAction 命 令 ， 则 TaskTracker 会 宣 














新 进行 











Lim 








初始 化 。 重 新 初始 化 过 程 与 TaskTracker 启 动 过 程 是 一 致 的 ， 可 参考 7.2 节 。 
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75 作业 目录 管理 








在 MapReduce 计 算 过 程 中 ，Map Task 要 将 大 量 中 间 数 据 写 入 本 地 磁盘 ， 而 这 些 数据 不 存在 备份 ， 一 旦 丢失 后 ， 就 必须 重新 计 
算 。 为 了 尽量 提高 这 部 分 数据 的 可 靠 性 和 并 发 写 性 能 ，Hadoop 人 允许 TaskTracker 配 置 多 个 挂 在 不 同 磁盘 的 目录 作为 中 间 结 果 存 放 目 
录 。 对 于 任意 一 个 作业 ，Hadoop 会 在 每 个 磁盘 中 创建 相同 的 目录 结构 ， 然 后 采用 轮 询 策 略 使 用 这 些 目录 (由 类 LocalDirAllocator 实 
现 ) 。 































































































TaskTracker 上 的 目录 可 分 为 两 种 :数据 目录 和 日 志 目 录 。 其 中 ， 数 据 目录 用 于 存放 执行 任务 所 必须 的 数据 (比如 可 执行 程序 
或 jar 包 ， 作 业 配 置 文件 等 ， 和 运行 过 程 中 产生 的 临时 数据 ， 由 参数 mapred.localdxr 指 定 ; 而 日 志 目 录 则 用 于 存放 TaskTracker 和 Task 
参数 hadoop.log.dr 指 定 。 下 面 我 们 分 别 介绍 这 两 种 目录 的 组 织 方式 。 

































































运行 时 输出 日 志 ， 














1. 数 据 目 录 











假设 某 个 TaskTracker 上 通过 参数 mapred.local.dr 配 置 了 NN 个 目录 /nmt/disk0，/mmvdisk1，..……….， /mnt/diskN-1， 且 这 NN 个 目录 正好 
挂 在 了 N 个 不 同 的 磁盘 ， 某 一 时 刻 用 户 提交 了 一 个 ID 为 jobidl 的 作业 ， 该 作业 包含 人 个 任务 〈 为 简化 说 明 ， 在 此 不 区 分 任务 类 
型 ) ， 则 TaskTracker 为 该 作业 创建 的 目录 结构 如 图 7-7 所 示 。TaskTracker 在 每 个 磁盘 上 为 该 作业 创建 了 相同 的 目录 结构 ， 且 采用 
轮 询 的 方式 使 用 这 些 目录 。 比 如 ， 对 于 任务 taskid1， 它 需要 创建 工作 目录 work 和 输出 结果 目录 output， 为 了 分 摊 写 负 
载 ，TaskTracker 可 能 将 work 目 录放 到 /mnt/disk1/ 磁 盘 上 ， 而 将 output 目 录放 到 /mnt/disk2 磁 盘 上 。 






































































































































~~ 


/AtaskTracker/$user/jobcache ae /taskTracker/$user/jobcache 
/jobid1 oe /jobid 1 


Al 7-7 作业 数据 目录 结构 


























考虑 到 Reduce Task 可 能 会 运行 失败 ， 且 每 个 Reduce Task 要 从 所 有 Map Task 中 获取 部 分 输入 ， 因 此 ， 所 有 任务 目录 不 会 在 作业 
运行 过 程 中 被 删除 ， 而 是 确认 作业 运行 完成 后 ， 统 一 将 其 删除 。 























2. 日 志 目录 








(1) 日 志 目 录 创 建 












































不 同 于 数据 目录 ，Hadoop 只 允许 TaskTracker 将 日 志 目录 存在 一 个 磁盘 上 。 一 个 典型 的 日 志 目录 结构 如 图 7-8 所 示 。 
TaskTracker 包 含 两 种 日 志 : 系统 日 志和 用 户 日 志 。 其 中 ， 系 统 日 志 是 TaskTracker 服 务 内 部 打印 的 运行 日 志 ， 存 放 到 文件 < 
tasktracker-name> .log#ll<tasktracker-name>.out'?; 而 用 户 日 志 存 放 在 userlogs 目 录 下 ， 且 按照 不 同 作业 不 同 任务 分 别 建立 子 目 
录 。 



















































































7-8 作业 日 志 目 录 结 构 
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如 果 TaskTracker 上 任务 多 、 日 志 量 大 ， 则 这 种 日 志 目 录 组 织 方式 可 能 成 为 TaskTracker 的 性 能 瓶颈 。 为 此 ， 从 Hadoop 
0.20.204.0 开 始 引入 了 多 磁盘 日 志 目 录 组 织 方式 : 系统 日 志 仍 被 直接 放 到 hadoop.logdir 目 录 下 ， 但 用 户 日 志 将 被 采用 轮 询 的 方式 将 
分 布 到 mapred.localdir 指 定 的 各 个 磁盘 目录 下 ， 同 时 为 了 保持 语义 不 变 ，TaskTracker 在 hadoop.logdir 目 录 下 创建 指向 这 些 目录 的 符 
号 链接 ， 有 具体 如 图 7-9 所 示 。 



























































<hadoop.log.dir>/ 

<hadoop.log.dir>/userlogs / 

<hadoop.log.dir>/userlogs /<jobid>/symlink -to-attempt -id=1 
<hadoop.log.dir>/userlogs /<jobid>/symlink -to-attempt -id-2 


<mapred local .dir-0>/userlogs/<jobid>/attempt-id-1 
<mapred .local.dir-1>/userlogs /<jobid>/attempt -id-2 
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7-9 多 磁盘 作业 日 志 目 录 结 构 


























这 种 用 户 日 志 目 录 组 织 方式 带 来 的 好 处 如 下 : 



























































口 可 以 高 效应 对 更 大 量 的 用 户 日 志 ， 且 TaskTracker 不 再 被 单 磁 盘 日 志 读 写 性 能 约束 ， 同 时 更 可 靠 ; 























ASS 


口 在 修改 很 少 代 码 的 前 提 下 ， 维 持 了 之 前 的 语义 。 




















(2) 日 志 目 录 清 理 











志 目 录 清 理 是 由 类 UserLogManager 实 现 的 。 它 包含 两 个 非常 重要 的 成 员 变 量 : taskLogsTruncater 和 userLogCleaner， 它 们 分 别 
IFA SRB AIA RISE, AAUP. 




























































































CitaskLogsTruncater: 用 户 输出 的 日 志文 件 可 能 很 大 ， 这 将 占用 大 量 磁盘 空间 ， 同 时 对 前 端 日 志 信 息 展示 也 不 够 友好 ， 为 
此 ，TaskTracker 通 过 TaskLogsTruncater 类 实现 了 日 志文 件 裁剪 功能 ， 即 当 任务 运行 完成 后 ，TaskTracker 将 按照 管理 员 要 求 对 各 个 
日 志文 件 进行 裁剪 ， 以 保证 日 志文 件 不 会 太 大 。TaskTracker 为 管理 员 提 供 了 两 个 可 配置 参数 : mapreduce.cluster.map.userlog.retain- 
size 和 mapreduce.cluster.reduce.userlog.retain-size， 分 别 用 于 配置 Map Task 和 Reduce Task 最 大 可 保留 的 日 志文 件 大 小 。 




















































































































OuserLogCleaner: 由 于 TaskTracker 将 所 有 作业 的 运行 日 志保 存 到 本 地 磁盘 上 ， 因 此 随 着 时 间 的 积累 ， 作 业 日 志 必 将 越 来 越 
多 。 为 了 避免 作业 日 志 占用 大 量 磁盘 空间 ，TaskTracker 通 过 userLosgCleaner 线 程 实现 了 日 志文 件 清理 功能 。TaskTracker 人 允许 一 个 作 
业 日 志 可 在 磁盘 上 的 保留 时 间 为 mapred. userlog.retain.hours (默认 为 24 小 时 ) ， 一 旦 超过 该 时 间 ，TaskTracker 会 将 该 作业 日 志 从 磁 
盘 上 删除 。 




































































7.6 ”启动 新 任务 





TaskTracker 最 重要 的 任务 之 一 是 启动 JobTracker 分 配 的 新 任务 并 周期 性 ; 
所 示 ， 大 致 经 历 两 个 步骤: 作业 本 地 化 和 启动 但 








7.6.1 任务 启动 过 程 分 析 


1. 作 业 本 地 化 


















是 否 是 第 一 次 
收 到 某 个 作业 
的 任务 ? 


Yes 


No 
Y 











创建 任务 目录 


W TaskTracker šmak 


任务 本 地 化 


7-10 ”TaskTracker 任 务 启动 流程 





图 





1 


作业 本 地 化 


本 地 化 (localize〉 是 指 在 TaskTracker 上 为 作业 和 任务 构造 一 个 运行 环境 ， 包 括 创建 作业 和 任务 的 工作 


下 载运 行 任务 相关 的 文件 ， 
E, HEN 


















































JA DARE AB Se 3 
TaskTracker 串 行 启动 各 个 任务 ， 














如 程 


E 序 jar 包 $ 字典 文件 等 , 





















































上报 它们 的 运行 状态 。 一 个 任务 的 启动 过 程 如 图 7 
E 务 (包括 任务 本 地 化 和 运行 任务 〉。 




















IR, 
设置 环境 变量 等 ， 可 分 为 作业 本 地 化 和 任务 本 地 化 。 在 同一 个 TaskTracker 
的 第 一 个 任务 完成 该 作业 的 本 地 化 工作 ， 后 续 任 务 只 需 进 行 任务 本 地 化 。 





10 


(从 HDFS 上 ) 


F 《比如 jar 包 ， 字 典 文件 等 ) 可 能 很 大 ， 这 使 得 任务 花费 较 长 时 间 从 HDFS 上 下 载 这 些 数 据 ， 如 果 


势必 会 延长 任务 的 启动 时 间 。 为 了 解决 该 问题 ，TaskTracker 采 用 多 线程 启动 任务 ， 即 为 每 个 任务 





单独 启动 一 个 线程 : 


void startNewTask (final TaskInProgress tip) { 
Thread launchThread=new Thread (new Runnable() { 
public void run() { 





RunningJob rjob=localizeJob (tip) ; // 作 业 本 地 化 
tip.getTask() .setJobFile (rjob.getLocalizedJobConf () .toString()) ; 
launchTaskForJob (tip, new JobConf (rjob.getJobConf()), rjob) ; 








为 了 防止 同一 个 作业 的 多 个 任务 同时 进行 作业 本 地 化 ，TaskTracker 需 要 对 相关 数据 结构 加 锁 。 一 种 常见 的 加 锁 方 法 是 ; 





RunningJob rjob; 

aig /7 对 号 cb 刁 介 

synchronized (rjob) {// 获 取 rjob 锁 

initializeJob (zjob) ; /* 作 业 本 地 化 。 如 果 作业 文件 很 大 ， 则 该 函数 运行 时 间 很 长 ， 这 导致 rjob 锁 
长 时 间 不 释放 */ 

} 






























































在 以 上 实现 方案 中 ， 作 业 本 地 化 过 程 会 一 直 占 用 fjob 锁 ， 这 导致 很 多 其 他 需要 该 锁 的 线程 或 者 函数 不 得 不 等 待 ， 如 
MapEventsFetcherThreadqd 线 程 、TaskTracker.getMap-CompletionEvents0 函 数 等 。 





























为 了 避免 作业 本 地 化 过 程 中 长 时 间 占 用 rjob 锁 ，TaskTracker 为 每 个 正在 运行 的 作业 维护 两 个 变量 ，localizing 和 localized， 分 别 


表示 正在 进行 作业 本 地 化 和 已 经 完成 作业 本 地 化 。 通 过 对 这 两 个 变量 的 控制 可 避免 作业 本 地 化 时 对 RunningJob 对 象 加 锁 ， 且 能 够 
保证 只 有 作业 的 第 一 个 任务 进行 作业 本 地 化 : 






















































































synchronized (rjob) { 
if (! rjob.localized) {// 该 作业 尚未 完成 本 地 化 工作 

while (rjob.localizing) {// 另 外 一 个 任务 正在 进行 作业 本 地 化 
rjob.wait (); // 等 待 作业 本 地 化 结束 
}/ /释放 rjob 锁 
if (! rjob.localized) {// 没 有 任务 进行 作业 本 地 化 
rjob.localizing=true: // 让 当前 任务 对 该 作业 进行 本 地 化 
} 
} 


} 

if (! rjob.localized) {// 运 行 到 此 ， 说 明 当 前 没有 任务 进行 作业 本 地 化 
initializeJob (rjob) ; // 进 行 作业 本 地 化 工作 

} 




























































































在 整个 作业 本 地 化 过 程 中 ，<localizing, localized 二 两 个 变量 值 变化 过 程 为 : 

















<false, false>—<true, false>— <true, true> 




















作业 的 第 一 个 任务 负责 为 该 作业 本 地 化 ， 有 具体 步骤 如 下 : 














步骤 1 将 凭据 文件 jobToken 和 作业 描述 文件 job.xml 下 载 到 TaskTracker 私 有 文件 目录 中 。 


















































TaskTracker 私 有 文件 目录 是 $ {mapred.localdir}/ttprivate， 其 中 ， 不 同 用 户 的 文件 放 到 不 同 子 目 录 下 ， 比 如 用 户 $user 提 交 的 作业 
$jobid 对 应 文件 放 在 $ {mapred.local.dir} /ttprivate/taskTracker/$user/jobcache/$jobid/ 目 录 下 。 此 外 ， 在 任务 运行 过 程 中 ， 任 务 启动 脚本 
taskjvmsh (具体 见 下 一 小 节 〉 也 存放 在 该 目录 下 。 












































步骤 2 将 其 他 初始 化 工作 交 给 TaskController.initializeJob 函 数 处 理 








o 

















TaskController 类 主要 用 于 控制 任务 的 初始 化 、 终 结 和 清理 等 工作 ， 当 前 默认 实现 是 DefaultTaskController。 
TaskController.initializeJob 函 数 的 主要 工作 是 创建 作业 相关 目录 和 文件 ， 最 终生 成 的 目录 结构 如 下 。 






































T$ {mapred. local.dir} /taskTracker/distcache/: TaskTracker 上 的 pubtc 级 别 分 布 式 缓存 ， 该 TaskTracker 上 所 有 用 户 的 所 有 作业 共享 
该 缓存 中 的 文件 





o 














口 $fmapred. local.dir} /taskTracker/$user/disteache/: TaskTracker 上 的 private 级 别 缓存 ， 用 户 $user 的 所 有 作业 共享 该 缓存 中 的 文 








过 JobConfgetJobLocalDir0 函 数 获取 。 此 外 ， 它 还 在 系统 

















O$ {mapred. local dir}/taskTracker/$user/jobcache/$jobid/: 用 户 $user 提 交 的 作业 $jobid 对 应 的 目录 。 

















口 $f{mapred. local.dir}/taskTracker/$user/jobcache/$jobid/work/: 作业 共享 目录 ， 可 作为 任务 的 数据 暂 存 目 录 或 者 共享 


























遇 性 中 ， 因 此 也 可 以 通过 System getProperty ("job.local.dir") 3&8 














DD $ {mapred. local. dir} /taskTracker/$user/jobcache/$jobidjjars/: 存放 作业 jar 文 件 和 展开 后 的 jar 文 件 。 程 序 相关 的 jar 文 伯 




















名 成 jobjar， 并 分 发 到 各 个 节点 上 ， 且 在 任务 运行 之 前 ， 

















O${mapred. local.dir} AaskTracker/$user/jobcache/$jobid/job.xml: 存放 作业 相关 的 配置 属性 。 

















2. 启 动 任务 

















Hadoop 自 动 展开 该 文件 。 





























口 $mapred. local.dir/taskTracker/$user/jobcache/$jobid/jobToken: 作业 和 凭据 文件 ， 用 于 保证 作业 运行 安全 。 








口 Smapred. local.dir/taskTracker/$user/jobcache/$jobid/job-acls.xml: 保存 作业 访问 控制 权限 。 


O $hadoop. log,dir/userlogs/$jobid/: 作业 日 志 存 放 目 录 。 











目录 ， 可 通 


区 。 





F 被 统一 命 











为 了 避免 不 同 任务 之 间 相 互 干扰 ，TaskTracker 为 各 个 任务 启动 了 独立 的 JVM。 也 就 是 说 ，JVM 相 当 于 包含 一 定 资源 量 的 容 



































器 ， 每 个 任务 可 在 该 容器 使 用 其 资源 运行 。 这 里 先 介绍 JVM 启 动 过 程 ， 然 后 介绍 任务 启动 过 程 。 












































根据 任务 类 型 ，TaskTracker 会 调用 不 同 的 TaskRunner 启 动 任 务 。 对 于 Map Task， 会 调用 MapTaskRunner， 而 Reduce 
ReduceTaskRunner， 但 任务 启动 最 终 均 是 由 TaskRunnerrun0) 方 法 完成 的 。 



































TaskRumner. run0 方 法 首先 准备 启动 任务 需要 的 各 种 信息 ， 包 括 启 动 命令 、 启 动 参数 、 环 境 变量 、 标 准 输出 流 、 标 








流 等 信息 ， 然 后 交 给 JvmManager 对 象 启动 一 个 JVM。 





























be 
































Task 则 调用 


















































准 错误 输出 


JvmManager 负 责 管理 TaskTracker 上 所 有 正在 使 用 的 JVYM， 包 插 启 动 、 停 止 、 杀 死 JVM 等 。 考 虑 到 一 般 情况 下 Map Task 和 


















































Reduce Task 占 用 的 














口 每 个 JVM 只 能 同时 运行 一 个 任务 ; 








口 每 个 TaskTracker 上 同时 启动 的 Map Task 和 Reduce Task 数 目 不 能 超过 Map slot 和 Reduce slot 数 目 ; 














资源 量 不 同 ，JvmManager 使 用 mapJvmManager 和 reduceJvmManaget 单 独 管理 两 种 类 型 任务 对 应 的 JVM 



















































































个 作业 的 同类 型 任务 使 用 。 这 一 点 可 从 JvwmID 中 看 出 ， 




















机 整 型 拼接 而 成 的 ， 比 如 jvm 201209031104 0010 m 482270223. 


























步骤 1 如 果 已 启动 JVM 数 目 低 于 上 限 数目 (Map slot 或 者 Reduce sot A) ， 则 直接 启动 JVM， 和 否则 进入 步骤 2。 





























步骤 2 ”查找 当前 TaskTracker 所 有 已 经 启动 的 JVM， 





口 当前 状态 为 空间 ; 




















口 复 用 次 数 未 超过 上 限 数 目 ; 




















找 出 满足 以 下 条 件 的 JVM: 


’ 且 规 定 : 





口 每 个 JVM 可 重复 使 用 以 减少 启动 开销 《重用 次 数 可 通过 参数 mapred.job.reuse.jvmnumtasks 指 定 ) ， 但 某 个 JVM 只 限于 同一 
它 是 某 个 作业 ID《〈 将 其 ID 标识 字符 串 9ob' 变 为 wm ， 任 务 类 型 和 一 个 随 











口 与 将 要 局 动 的 任务 同属 一 个 作业 《通过 JvmID 可 获取 作业 ID) 。 



































如 果 找 到 这 样 的 JVM， 则 可 继续 复 用 而 无 须 启动 新 的 JVM， 和 否则 进入 步骤 3 


N] 














步骤 3 ”查找 当前 TaskTracker 所 有 已 经 启动 的 VM， 如 果 满足 以 下 两 个 条 件 之 一 ， 则 直接 将 该 JVM 杀 掉 ， 并 启动 一 个 新 的 
JVM. 


























口 复 用 次 数 已 达到 上 限 数目 且 与 新 任务 同属 一 个 作业 ; 


























口 当前 处 于 空闲 状态 但 与 新 任务 不 属于 同一 作业 。 











启动 JVM 是 由 JvmRunner 线 程 完成 的 ， 它 进一步 调用 了 TaskController 中 的 launchTask 方 法 。 在 DefaultTaskController 实 现 中 ， 该 方 
去 首先 在 本 地 磁盘 创建 任务 工作 目录 ， 接 着 将 任务 启动 命令 写 到 Shel 脚 本 taskjvmsh 中 ， 并 直接 使 用 以 下 命令 运行 该 脚本 以 启动 任 
务 : 
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bash-c taskjvm.sh 








其 中 ， 一 个 taskjvmsh 实 例如 下 : 














export JVM PID=echo$$ 

export HADOOP CLIENT OPTS="-Dhadoop.tasklog.taskid=attempt_201209010905 0002 
m_000000_ 0- Dhadoop.tasklog.iscleanup=false-Dhadoop.tasklog.totalLogFileSize=0" 
export SHELL="/bin/bash" 

export HADOOP_WORK_DIR="/tmp/mapred/taskTracker/intuser/jobcache/ 

job 201209010905 0002/attempt 201209010905 0002 m 000000 0/work" 

export HOME="/homes/" 

export LOGNAME="dongxicheng" 

export HADOOP TOKEN FILE LOCATION="/tmp/mapred/taskTracker/intuser/jobcache/ 
job 201209010905 0002/jobToken" 

export HADOOP ROOT LOGGER="INFO, TLA" 

export LD LIBRARY PATH=" /tmp/mapred/taskTracker/intuser/jobcache/ 





job 201209010905 _0002/attempt 201209010905 0002 m 000000 O/work: /usr/lib/jvm/ 
java-1.6.0-openjdk-1.6.0.0.x86 64/jre/lib/amd64/server: /usr/lib/jvm/java- 
.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64: /usr/lib/jvm/java-1.6.0-openjdk- 
1.6.0.0.x86 64/jre/../lib/amd64" 
export USER="dongxicheng" 
exec setsid'/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java"..... 
'-Dhadoop. log. dir=/home/dongxicheng/hadoop-1.0.0/libexec/../logs' 
'-Dhadoop.root.logger=INFO, TLA' 
'-Dhadoop.tasklog.taskid=attempt_201209010905 0002 m 000000 0' 
'-Dhadoop.tasklog.iscleanup=false''—-Dhadoop.tasklog.totalLogFileSize=0' 
‘org.apache.hadoop.mapred.Child''127.0.0.1''47655'' attempt 201209010905 0002 __ 
m 000000 _0''/home/ 
dongxicheng/hadoop-1.0.0/libexec/../logs/userlogs/job_201209010905_0002/ 
attempt 201209010905 0002 m 000000 0''400940185'</dev/null 1>>/home/ 
dongxicheng/hadoop-1.0.0/libexec/../logs/userlogs/job 201209010905 0002/ 
attempt _ 201209010905 0002 m 000000 0/stdout2>>/home/ 
dongxicheng/hadoop-1.0.0/libexec/../logs/userlogs/job 201209010905 0002/ 
attempt _201209010905 0002 m 000000 0/stderr 









































可 以 看 到 ， 最 终 是 通过 org.apache.hadoop.mapred.Child 类 运行 任务 的 ， 即 








org.apache.hadoop.mapred.Child<host><port><task-attempt-—id><log-location><jvm-id> 




















上 面 代 码 中 的 五 个 输入 参数 分 别 表示 TaskTracker 的 了 一 、 端 口号 、Task Attempt ID、 日 志 位 置 和 JVM ID。 














S 











其 中 ，org.apache.hadoop.mapred.Child 类 的 核心 代码 框架 如 下 : 





public static void main (String[]args) throws Throwable{ 
/ /创建 RPC Client， 启 动 日 志 同 步 线 程 

while (true) {// 不 断 询 问 TaskTracker， 以 获取 新 任务 

JvmTask myTask=umbilical.getTask (context) ; // 获 取 新 任务 
if (myTask.shouldDie ()) {//JVM 所 属 作业 不 存在 或 者 被 杀 死 
break; 
selse{ 
if (myTask.getTask()==null) {// 暂 时 没有 新 任务 
/ /等 待 一 段 时 间 继 续 询 问 TaskTracker 















































Continue; 











} 

// 有 新 任务 ， 进 行 任务 本 地 化 
taskFinal.run (job, umbilical) ; // 启 动 该 任务 
// 如 果 JVM 复 用 次 数 达到 上 限 数目 ， 则 直接 退出 
if (numTasksToExecute>0& &++numTasksExecuted==numTasksToExecute) { 
break; 

} 

} 

} 






























































其 中 任务 本 地 化 涉及 内 容 如 下 : 











D 将 任务 相关 的 一 些 配置 参数 添加 到 作业 配置 JobConf 中 (如 果 参 数 名 相同 ， 则 会 覆盖 ) ， 形 成 任务 自己 的 配置 JobConf， 并 
采用 轮 询 的 方式 选择 一 个 目录 存放 对 应 的 任务 对 象 配 置 文件 。 也 就 是 说 ， 任 务 的 JobCon 瓮 由 作业 的 JobCon 三 任务 特定 参数 组 成 
的 ， 其 中 ， 任 务 特定 参数 如 表 7-3 所 示 。 



















































































表 7-3 任务 特定 参数 列表 








mapred.job.id 作业 ID 

mapred. jar 作业 的 job.jar 所 在 目录 

job.local.dir 作业 共享 目录 

mapred.tip.id 任务 ID 

mapred.task.id Task Attempt ID 

mapred.task.is.map 是 否 为 Map Task 

mapred.task.partition int 任务 在 作业 中 的 ID 

map.input.file String Map Task 的 输入 文件 

map.input.start Map Task 的 输入 数据 在 输入 文件 中 的 偏 移 量 
map.input.length Map 输入 InputSplit 的 长 度 











2) 在 工作 目录 中 建立 指向 分 布 式 缓存 中 所 有 数据 文件 的 链接 ， 以 便 能 够 直接 使 用 这 些 文件 。 




















最 终 ， 形 成 的 任务 目录 结构 如 下 。 








DD $ {mapred. local.dir} /taskTracker/Suser/jobcache/$jobid/Staskid: 作业 $jobid 中 的 任务 $taskid 对 应 的 目录 。 








O$ {mapred.local.dir} /taskTracker/$user/jobcache/$jobid/Staskidjob.xml: 任务 本 地 化 后 产生 的 与 该 任务 对 应 的 配置 文件 。 

















OS$ {mapred.local.dir} /task Tracker/$user/jobcache/$jobid/$taskid/splt.info: 任务 的 InputSpkt 元 数据 信息 ， 仅 用 于 IsolationRunner 调 试 。 

















O$ fmapred. local. dir} /taskTracker/Suser/jobcache/$jobid/$taskid/output: 存放 中 间 输 出 文件 的 目录 ， 比 如 Map Task 的 中 间 输 出 结 








O$ {mapred.local.dir} /taskTracker/$user/jobcache/$jobid/Staskid/work: 任务 的 工作 目录 。 











O$ {mapred.local.dir} /task Tracker/$user/jobcache/$jobid/$taskid/work/tmp: 任务 的 临时 目录 。 用 户 可 通过 参数 mapred.child.tmp 设 置 
Map Task 和 Reduce Task 的 临时 目录 ， 默 认 值 是 .tmp。 如 果 该 值 不 是 绝对 路 径 ， 则 任务 是 相对 于 工作 目录 的 相对 路 径 。 当 启动 JVM 
时 ， 会 将 -Djava.io.tmpdir=’the tmp dir 作 为 启动 参数 。 



































口 $hadoop. log dir/userlogs/$jobid/$taskid: 作业 $jobid 中 任务 $taskid 的 日 志 目 录 。 该 目录 下 的 主要 文件 或 子 目录 如 下 。 

















O$hadoop.log.dir/userlogs/$jobid/S$taskid/stdout: 应 用 程序 打印 的 标准 输出 数据 ， 比 如 Java 应 用 程序 








印 的 输出 数据 。 


LOG (INFO) 打印 的 日 志 。 
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O $hadoop. log. dir/userlogs/$jobid/Staskid/stderr: 应 用 程序 打印 的 标准 错误 输出 数据 ， 比 如 Java 应 用 程序 中 使 用 System.err.print0 函 
数 打印 的 输出 数据 。 






































O$hadoop.log.dir/userlogs/$jobid/Staskid/syslog: 应 用 程序 和 MapReduce 框 架 打印 的 系统 日 志 ， 


























比如 应 用 程序 中 使 用 

















O$hadoop.log.dir/userlogs/$jobid/$taskid/profile.out: profling 日 志 。 当 用 户 设置 配置 选项 mapred.task.profile=true 时 ，TaskTracker 会 

























































































O$hadoop.log.dir/userlogs/$jobid/$taskid/debugout: Debug 脚 本 的 标准 输出 。 





co 


mapred.reduce.task.debug,script 指 定 任务 失败 时 需 运行 的 调试 脚本 。 





Debug 肝 本 的 标准 输出 举例 如 下 : 























步骤 1 编写 应 用 程序 。 























为 了 简化 问题 ， 我 们 采用 Hadoop Streaming 编 写 应 用 程序 。 为 了 能 够 让 任务 运行 失败 ， 我 们 在 Map Task 处 开 














时 ， 打 印 一 个 空 指针 ， 对 应 的 C++ 代码 如 下 : 


#include<string> 
#include<iostream> 

using namespace std; 

int main() { 

string key; 

int errorno=1; 

while (cin>>key) { 
cout<<key<<"\t"<<"1"<<endl; 
if Cerrornott+==5) { 

int*p=NULL; 
cout<<*p<<endl; // 当 处 理 到 第 5 行 记录 时 ， 让 Map Task 运 行 失败 
} 

} 

return 0; 


} 














编译 以 上 程序 生成 可 执行 程序 Mapper， 我 们 将 该 可 执行 文件 作为 MapReduce 程 序 的 Mapper。 

















步骤 2 编写 作业 提交 脚本 。 


St 

















写 应 用 程序 提交 脚本 ， 内 容 如 下 : 





gs 














bin/hadoop jar contrib/streaming/hadoop-streaming-1.0.0.jar\ 
-mapper Mapper\ 

-reducer NONE\ 

-input/home/dongxicheng/input\ 
-output/home/dongxicheng/output\ 

-file Mapper\ 

-file debug_map.sh\ 

-mapdebug./debug_map.sh 





其 中 ，Map Task 调 试 脚本 debug_ map.sh!!! 内 容 如 下 : 


core=find.-name'core*' 
gdb-quiet./Mapper-c$core-ex'info threads'-ex'backtrace'-ex'quit' 






































用 户 可 通过 参数 mapred.map.task.debug.script 和 


任务 的 profling 功 能 ， 这 会 根据 用 户 要 求 采 集 任务 的 运行 时 信息 并 保存 到 profle.out 文 件 中， 以 方便 用 户 对 应 用 程序 调 优 。 




















步骤 3 ”准备 好 输入 数据 后 ， 提 交 作业 ， 可 在 $hadoop.log.dir/userlogs/$jobid/$taskid/debugout 中 看 到 调试 脚本 输出 结果 。 





























IK 


$hadoop. log.dir/userlogs/$jobid/$taskid/log index: 日 志 索 引文 件 。 当 JVM 人 允许 复 用 时 ， 所 有 复 月 














HE 





E 第 5 行 数据 记录 





个 JVM 的 任务 会 将 











志保 存 


= 























第 一 个 任务 的 日 志文 件 中 ， 因 此 ， 需 要 一 个 日 志 索 引文 件 保存 日 志 实 际 存放 位 置 以 及 每 个 任务 对 应 的 标准 输出 日 志 、 标 准 错误 
日 志和 系统 日 志 在 文件 stdout、stderr 和 syslog 中 的 偏 移 量 ， 有 具体 格式 如 下 : 
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LOG DIR: <the dir where the task logs are really stored> 
stdout: <start-offset in the stdout file><length> 
stderr: <start-offset in the stderr file><length> 
syslog: <start-offset in the syslog file><length> 





























[1] 由 于 调试 信息 是 从 core 文 件 中 获取 的 ， 因 此 提交 作业 前 应 修改 Linux 相 关 配 置 以 确保 能 够 生成 core 文 件 。httpVlxc.sourceforee.net/ 


7.6.2 


资源 隔离 是 指 为 不 同 任 


资源 隔离 机 制 





Linux Container!!! 等 。 























































































































务 提供 



































可 独立 使 



































































































































j 的 计算 资源 以 避免 它们 相互 于 扰 。 当 





















































前 存在 很 多 资源 隔离 技术 ， 比 如 硬件 虚拟 化 、 
































































































































































































































前 面 提 到 ，Hadoop 为 各 个 任务 启动 独立 的 Java 虚 拟 机 以 达到 资源 隔离 的 目的 。 然 而 ， 考 虑 到 用 户 应 用 程序 可 能 会 创建 其 他 子 
进程 ， 如 Hadoop Pipes (或 者 Hadoop Streaming) 编写 的 MapReduce 应 用 程序 中 每 个 任务 至 少 由 Java 进 程 和 C++ 进程 两 个 进程 组 成 ， 
这 难以 通过 创建 单独 的 虚拟 机 达到 资源 隔离 的 效果 。 为 了 弥补 这 个 不 足 ， 在 Linux 环 境 《〈 其 他 操作 系统 暂 不 支持 ) 中 ，Hadoop 在 
各 个 TaskTracker 上 启动 一 个 TaskMemoryManagerThread 线 程 以 监控 各 个 任务 内 存 使 用 情况 ， 一 旦 发 现 某 个 任务 使 用 内 存 过 量 ， 则 
直接 将 其 杀 死 。 

1.MapReduce 作 业 的 配置 参数 

由 于 不 同 的 MapReduce 作 业 对 内 存 的 需求 不 同 ， 因 此 ，Hadoop 提 供 了 各 种 配置 参数 帮助 用 户 和 管理 员 合理 地 使 用 内 存 资 源 。 

些 参数 可 分 为 两 类 ， 一 类 是 用 户 配置 参数 ， 比 如 用 户 根据 自己 应 用 程序 特点 为 Map Task 和 Reduce Task 设 定 的 最 大 内 存量 ; 另 
类 是 管理 员 配 置 参数 ， 比 如 为 防止 用 户 滥 用 内 存 资源 ， 管 理 员 可 限定 每 个 任务 的 最 大 可 用 内 存量 。 

d) 用 户 配置 参数 

mapred. job. {map|reduce}.memory.mb: 作业 的 Map Task 或 Reduce Task 最 多 使 用 的 内 存量 (单位: MB) 。 

(2) 管理 员 配 置 参数 

口 mapred. cluster.max. {map|reduce}.memory.mb: 用 户 可 设置 的 Map Task 或 Reduce Task 最 多 使 用 内 存量 的 上 限 值 〈 单 位 : 

MB) 。 

口 mapred. job. {map|reduce}.memory.mb: TaskTracker 上 每 个 Map slot 或 Reduce slot 代 表 的 内 存量 C: MB) 。 注 意 ， 有 些 调 
度 器 会 根据 该 参数 值 和 任务 内 存 需求 为 任务 分 配 多 个 slot， 比 如 Capacity Scheduler. 

2.MapReduce 作 业内 存 监 控 

TaskMemoryManagerThread 线 程 每 隔 一 段 时 间 (由 参数 mapred.tasktracker.taskmemorymanager.monitoring-interval 指 定 ， 默 认 是 5 s) 





扫描 所 有 正在 运行 的 个 


步骤 1 


在 /proc 目 录 下 ， 有 大 量 





信息 say o 
这 样 ， 


为 了 更 























E 务 ， 


构造 进程 树 。 
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以 整数 命名 的 目录 ， 
全 面 地 监控 一 个 任 








并 按照 以 下 步骤 检查 它们 使 用 的 内 存量 是 否 超过 上 限 值 。 




















这 些 整数 是 茶 个 正在 运行 的 进程 的 进程 号 


， 而 目 
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通过 监控 该 进程 树 使 
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步骤 2 FRESA 


在 Linux 系 统 中 ， 














的 内 存 总 量 可 严格 限制 一 个 任务 使 用 的 内 存量 。 
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程 的 运行 时 信 





的 时 间 (单位 ，jifes)、 


AN: 


“ €[0-9- 


sy? 





/proc/<pid>/stat 文 件 中 包含 了 进程 pid 的 运行 时 信 
具体 包括 进程 名 称 、 父 


rll 
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存 使 








j 量 是 否 超过 内 存量 最 





大 值 。 


















































ay? 


TaskTracker 通 过 读 取 /proc/<pid>/stat 文 件 





录 下 
构造 出 









































则 是 该 进程 运行 时 的 一 些 











以 该 任务 进程 为 根 的 进程 树 。 








进程 的 PID、 父 进程 组 号 、Session ID 在 



































占 月 











1+) \\s C[*\\s]+) \\s[*\\s]\\s C[0-9- 
9]+) \\s C[0-9]+) \\s C[0-9- 


]+) \\s C[0-9- 


晶 虚 拟 内 存 大 小 〈 单 位: page) 和 占用 物理 内 存 大 小 C 











]+) \\s C[0-9- 
]+\\s) {7} ([0-9]+) \\s ([0-9]+) (\\s[0-9-]+) {15} 


单位 : page) 等 。 


]+) \\s C[0-9- 





TaskTracker fii 


而 TaskTracker 正 是 使 用 正则 表达 式 从 该 文件 中 提取 进 
用 户 态 运行 的 时 间 (单位 : jiffies) 、 

















核心 态 运行 
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的 正则 表 万 
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文人 























获取 每 个 page 对 应 的 内 存量 (单位:，B) : 


getconf PAGESIZE 








F/proc/ 二 pid 二 /stat 中 包含 的 内 存 大 小 单位 为 page。 为 了 获取 以 字 节 为 单位 的 内 存 信息 ，TaskTracker 通 过 执行 以 下 Shell 命 令 























动 进 程 的 年 


如 果 一 个 任务 对 应 的 进程 树 中 所 有 进程 〈 年 龄 大 于 0) 总 内 存 超过 〈 用 
量 超 过 (用 户 设置 的 ) 最 大 值 ， 


计算 所 有 正在 运行 的 和 
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判断 任务 总 内 存 使 用 量 是 否 超 过 总 可 用 内 存量 。 





























































































































FE 龄 加 1。 在 此 基础 上 ， 选 择 被 杀 和 死人 


户 设置 的 ) 最 大 值 的 两 倍 ， 或 者 所 有 各 














则 认为 该 任务 过 量 使 用 内 存 ， 直 接 将 其 杀 死 ， 并 将 状态 标注 为 FAILED。 












































[ 务 当前 使 








ja 





















































不 断 选择 进度 最 慢 的 任务 并 将 其 杀 掉 ， 直 到 内 存 使 用 量 降 到 可 用 内 存 总 量 以 下 。 






































需要 注意 的 是 ， 在 下 一 代 MapReduce《〈 见 第 12 章 ) 中 ， 同 时 增加 了 对 内 存 资源 和 CPU 资源 的 隔离 机 制 ， 但 采 月 


Ti 女 


案 不 同 。 对 于 内 存 资源 ， 为 了 能 够 更 灵活 地 控制 内 存 使 用 量 ， 它 仍 采 用 了 本 节 所 述 的 线程 监控 的 方案 。 采 用 这 利 
H T “fork(t+exec( 的 方案 ， 子 进程 创建 瞬间 ， 它 使 用 的 内 存量 与 父 进程 一 致 ， 从 外 面 看 来 ， 
线程 监控 的 方法 可 防止 这 种 情况 下 导致 swap 操 作 。 对 于 CPU 资源 ， 则 和 采 


是 Java 中 创建 子 进程 采 月 
内 存量 瞬间 翻 倍 ， 然 后 又 降下 来 ， 


资源 限 
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出 | 
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具体 可 参考 YARN-3 l, 
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通过 以 上 信息 可 计算 当前 每 个 运行 的 任务 使 用 的 内 存 总 量 。 但 需要 注意 的 是 ， 不 能 仅 赁 该 内 存量 是 否 超过 设 定 的 内 存 最 高 值 
决定 杀 死 一 个 任务 。 在 创建 一 个 子 进程 时 ，JVM 采 用 了 "ork0+exec0" 灶 型 ， 这 意味 着 进程 创建 之 后 、 执 行 之 前 会 复制 一 份 父 进程 
内 存 空间 ， 进 而 使 得 进程 树 在 某 一 小 段 时 间 内 存 使 用 量 翻 倍 。 为 了 避免 误杀 任务 ，Hadoop 赋 予 每 个 进程 年 龄 属性， 并 规定 刚 启 
1， 且 TaskMemoryManagerThread 线 程 每 更 新 一 次 ， 各 个 进程 名 














E 务 的 标准 如 














的 内 存 总 量 ， 如 果 超 过 系统 可 用 内 存 总 量 〈slot 数 与 slot 对 应 内 存 乘积 ) ， 则 TaskTracker 会 


的 资源 隔离 方 
机 制 的 主要 原因 

















一 个 进程 使 用 
































| 了 Cegroups 进 行 
































Ln] BS 








这 里 的 内 存 指 的 是 虚拟 内 存 。 从 0.21.0 版 本 开始 ，Hadoop 人 多 许 设置 物理 


























https://issues.apache. org/jira/browse/MAPREDUCE- 1221. 
[2] https//Assues. apache. org/jira/browse/YARN-3 


内 存 ， 





7.7 小 结 




















本 章 从 TaskTracker 架 构 、TasTracker 行 为 、 作 业 目 录 管理 等 几 个 方面 深入 分 析 了 TaskTracker 工 作 原 理 及 其 实现 。 





























TaskTracker 以 服务 的 形式 存在 ， 通 过 心跳 机 制 向 JobTracker 汇 报 任务 运行 状态 ， 并 索取 来 自 JobTracker 的 各 种 命令 























TaskTracker 收 到 的 命令 包括 启动 任务 (LaunchTaskAction) 、 提 交 任 务 (CommitTaskAction) 、 杀 死 任 务 (KillTaskAction) ~ 
杀 死 作业 CKilobAction) 和 重新 初始 化 〈TaskTrackerReinitAction) 五 种 。TaskTracker 收 到 这 些 命令 后 ， 会 按照 要 求 执 行 相应 的 操 
























































TaskTracker 最 重要 的 功能 之 一 是 启动 新 任务 。 一 个 任务 的 启动 过 程 大 体 包括 两 步 : 作业 本 地 化 和 任务 启动 。 为 了 进行 资源 隔 
离 ，TaskTracker 为 每 个 任务 启动 独立 的 Java 虚 拟 机 。 此 外 ，TaskTracker 启 动 了 一 个 额外 的 内 存 监控 进程 以 防止 任务 滥用 内 存 资 









































总 体 上 说 ，TaskTracker 扮 演 着 “通信 枢纽 的 角色 ， 是 JobTracker 与 Task 之 间 的 “沟通 桥梁 ”。 












































至 此 ， 我 们 已 经 剖析 了 JobTracker 和 TaskTracker 两 个 
Task 两 种 Task 的 内 部 实现 细节 。 





要 服务 的 实现 。 接 下 来 ， 我 们 将 介绍 Task 实 现 ， 包 括 Map Task 和 Reduce 


[fuil 
PER 
hi 




















第 8 章 ”Task 运行 过 程 分 析 














大 家 都 知道 ， 当 我 们 需要 编写 一 个 简单 的 MapReduce 作 业 时 ， 只 需 实现 map0 和 reduce0 两 个 函数 即 可 ， 一 旦 将 作业 提交 到 集群 上 











后 ，Hadoop 内 部 会 将 这 两 个 函数 封装 到 Map Task 和 Reduce Task 中 ， 同 时 将 它们 调度 到 多 个 节点 上 并 行 执行 ， 而 任务 执行 过 程 9 
的 数据 跨 节 点 传输 ， 记 录 按 key 分 组 等 操作 均 由 Task 内 部 实现 好 了 ， 用 户 无 须 关 心 。 
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[能 涉及 


为 了 帮助 读者 深入 了 解 Map Task 和 Reduce Task 内 部 实现 原理 ， 在 本 章 中 ， 我 们 将 Map Task 分 解 成 Read、Map、Colect、Spil 和 Conbine 





五 个 阶段 ， 将 Reduce Task 分 解 成 Shuffe、Merege、Sort、Reduce 和 Write 五 个 阶段 ， 并 依次 详细 齐 析 每 个 阶段 的 内 部 实现 细节 。 


8.1 ” Task 运行 过 程 概述 


















































在 MapReduce 计 算 框架 中 ， 一 个 应 用 程序 被 划分 成 Map 和 Reduce 两 个 计算 阶段 ， 它 们 分 别 由 一 个 或 者 多 个 Map Task 和 Reduce Task 组 


成 。 其 中 ， 每 个 Map Task 处 理 输 入 数据 集合 中 的 一 片 数据 (InputSplt〉 ， 并 将 产生 的 若干 个 数据 片段 写 到 本 地 磁盘 上 ， 而 Reduce Task 则 从 
每 个 Map Task 上 远程 拷贝 相应 的 数据 片段 ， 经 分 组 聚集 和 归 约 后 ， 将 结果 写 到 HDFS 上 作为 最 终结 果 ， 有 具体 如 图 8-1 所 示 。 总 体 上 看 ，Map 
Task 与 Reduce Task 之 间 的 数据 传输 采用 了 pul 异 型 。 为 了 能 够 容错 ，Map Task 将 中 间 计 算 结 果 存 放 到 本 地 磁盘 上 ， 而 Reduce Task 则 通过 




































































HITP 请 求 从 各 个 Map Task 端 拖 取 (pulD 相应 的 输入 数据 。 为 了 更 好 地 支持 大 量 Reduce Task 并 发 从 Map Task 端 拷贝 数据 ，Hadoop 采 用 了 























Jetty Server 作 为 HTTP Server 处 理 并 发 数据 读 请 求 。 








Shuffle Phase Sort Phase Reduce Phase 
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TaskTrack TaskT: 
askTracker Other Task Trackers askTracker 


8-1 Map/Reduce Task 运 行 过 程 























对 于 Map Task 而 言 ， 它 的 执行 过 程 可 概述 为 : 首先 ， 通 过 用 户 提供 的 InputFormat 将 对 应 的 InputSplit 解 析 成 一 系列 keyvalue， 
































依次 交 


给 用 户 编写 的 map0 函 数 处 理 ， 接 着 按照 指定 的 Partitioner 对 数据 分 片 ， 以 确定 每 个 keyvalue 将 交 给 哪个 Reduce Task 处 理 ， 之 后 将 数据 交 给 





















































用 户 定义 的 Conzbiner 进 行 一 次 本 地 规约 (用 户 没 有 定义 则 直接 跳 过 )〉; 最 后 将 处 理 结果 保存 到 本 地 磁盘 上 。 

















对 于 Reduce Task 而 言 ， 由 于 它 的 输入 数据 来 自 各 个 Map Task， 因 此 首先 需 通 过 HITP 请 求 从 各 个 已 经 运行 完成 的 Map Task 上 拷贝 对 应 
的 数据 分 片 ， 待 所 有 数据 拷贝 完成 后 ， 再 以 key 为 关键 字 对 所 有 数据 进行 排序 ， 通 过 排序 ，key 相 同 的 记录 聚集 到 一 起 形成 若干 分 组 ， 然 










































































待 
后 将 每 组 数据 交 给 用 户 编写 的 reduce0 函 数 处 理 ， 并 将 数据 结果 直接 写 到 HDFS 上 作为 最 终 输 出 结果 。 


























在 接 下 来 的 几 节 中 ， 我 们 将 逐步 深入 分 析 Map Task 和 Reduce Task 内 部 实现 ， 并 剖析 其 设计 原理 和 实现 细节 。 











8.2 


在 Map Task 和 Reduce Task 实 现 过 程 中 用 到 了 大 量 数据 结构 和 算法 ， 我 们 选取 了 




















前 面 提 到 ， 
(也 就 是 Reduce Task 的 输 























按照 MapReduce 语 义 ，Reduce Task 需 将 拷贝 
此 ，Hadoop 实 现 了 基于 排序 的 分 组 算法 。 但 考虑 到 若 完 全 
各 个 Map Task 对 输出 数据 进行 











序 策略 : 先 











在 任务 运行 过 程 中 ， 为 了 能 够 让 JobTracker 获 取 但 











j 户 可 通过 InputFormat 和 OuputFormat 琴 
入 格式 ) 。 考 虑 到 Map Task 
避免 不 必要 的 磁盘 和 网 络 ] 











条 新 数据 ， 该 线程 将 通过 RPC 告 知 TaskTracker， 并 











8.2.1 “IFile 存 储 格式 


IFile 是 一 种 支持 行 压缩 的 存储 格式 。 通 常 而 言 ， 





基本 数据 结构 和 算法 



































的 输出 文件 需要 到 磁盘 | 
开销 ，Hadoop 内 部 实现 了 支持 行 压缩 的 数据 存储 格式 










































































次 局 部 排序 
























































自 各 个 Map Task 端 的 数据 按照 key 进 行 分 组 后 才能 交 给 reduceO 函 数 处 理 ， 
Reduce Task 进 行 全 局 排序 会 产生 性 能 瓶颈 ， 
， 然 后 由 Reduce Task 进 行 





E 务 执行 进度 ， 各 个 任务 会 创建 一 个 进度 汇报 线程 Reporter， 
TaskTracker 通 过 心跳 进一步 告诉 JobTracker。 





文件 或 者 内 存 文件 中 。 为 了 尽 可 能 减少 Map Task 写 入 磁盘 数据 量 和 跨 网 络 传输 数 扩 

















提供 了 Zib〈 默 认 压 缩 方式 ) 、BZip2 等 压缩 算法 。 如 果 











口 mapred. compress.map.output: 是 否 支持 中 间 输 则 









































ConmmpressionCodec 接 口 以 提供 压缩 输出 流 和 解压 缩 输入 流 。 























HJ 








TFilejE XPI CHERE RAE KE ft 8 


3 J 压缩 机 制 ， 


hy ESC PPI RAE BH 





用 户 想 启 











结果 压缩 ， 默 认为 人 ase。 














Hadoop 会 为 每 条 记录 的 key 和 value 值 进行 压缩 。 























用 数据 压缩 功能 ， 则 需 为 作业 添加 以 下 i 














其 中 几 个 非常 核心 的 部 分 进行 介绍 。 


个 组 件 自 定义 作业 的 输入 输出 格式 ， 但 并 不 能 自 定 义 Map Task 的 输出 格式 
上 并 被 Reduce Task 远 程 找 贝 ， 为 尽 可 能 减少 数据 量 以 








JFile. 








为 
Hadoop 采 用 了 分 布 式 排 











一 次 全 局 排序 。 




















只 要 任务 处 理 











Map Task 中 间 输 出 结果 和 Reduce Task 远 程 找 贝 结果 被 存放 在 下 je 格式 的 磁盘 











量 ，IEie 文 持 按 行 压缩 数据 记录 。 当 前 Hadoop 
个 配置 选项 。 





























口 mapred. map.output.compression.codec: 压缩 器 (默认 是 基于 Zlib 算法 的 压缩 器 DefaulktCodec) 。 任 何 一 个 压缩 器 需 实现 


局 记录 ， 每 条 数据 记录 格式 为 : 





<key-len, value-len, 


key, value> 























IFile 文 件 读 写 操作 由 类 下 je 实现 ， 该 类 中 包含 


由 于 Map Task 会 按照 key 值 对 输出 数据 进行 排 月 





取 一 个 IFieg《〈 对 于 内 存 中 的 数据 读 取 ， 则 使 月 
了 IFileOutputStream 和 和 IFileInputStream 两 个 支持 CRC32 校 验 的 类 ， 






























































具体 如 图 8-2 所 示 。 


， 因 此 IFEie 通 常 保 存 的 是 有 序数 据 集 。 


个 重要 内 部 类 : Wiriter 和 Reader， 分 别 
HInMemoryReader) 。 此 外 ， 为 了 保 订 





Ly 











用 于 Map Task 生 成 下 je 和 Reduce Task 读 








FE 数据 一 致 性 ，Hadoop 分 别 为 Writer 和 Reader 提 供 


1 
IFile.Reader 
EN 
IFile.InMemoryReader 


8-2 IFike 类 关系 图 













8.2.2 ”排序 














排序 是 MapReduce 框 架 中 最 重要 的 操作 之 一 。Map Task 和 Reduce Task 均 会 对 数据 (按照 key)〉 进行 排序 。 该 操作 属于 Hadoop 











的 默认 行为 。 作 














E 何 应 用 程序 中 的 数据 均 会 被 排序 ， 而 不 管 逻 辑 上 是 否 需要 。 


















































对 于 Map Task， 它 会 将 处 理 的 结果 和 暂时 放 到 一 个 缓冲 区 中 ， 当 缓冲 区 使 用 率 达 到 一 定 阔 值 后 ， 再 对 缓冲 区 中 的 数据 进行 一 次 
排序 ， 并 将 这 些 有 序数 据 以 IFik 文 件 形式 写 到 磁盘 上 ， 而 当 数 据 处 理 完毕 后 ， 它 会 对 磁盘 上 所 有 文件 进行 一 次 合并 ， 以 将 这 些 文 
































件 合并 成 一 个 大 的 有 序 文件 。 

































































对 于 Reduce Task， 它 从 每 个 Map Task 上 远程 找 贝 相应 的 数据 文件 ， 如 果 文 件 大 小 超过 一 定 阔 值 ， 则 放 到 磁盘 上 ， 和 否则 放 到 内 
存 中 。 如 果 磁 盘 上 文件 数目 达到 一 定 阐 值 ， 则 进行 一 次 合并 以 生成 一 个 更 大 文件 ， 如 果 内 存 中 文件 大 小 或 者 数目 超过 一 定 阐 值 ， 













































































则 进行 一 次 合 3 














后 将 数据 写 到 磁盘 上 。 当 所 有 数据 拷贝 完毕 后 ，Reduce Task 统 一 对 内 存 和 磁盘 上 的 所 有 数据 进行 一 次 合并 。 












































在 Map Task 和 Reduce Task 运 行 过 程 中 ， 绥 冲 区 数据 排序 使 用 了 Hadoop 自 己 实现 快速 排序 算法 ， 而 正 衣 文件 合并 则 使 用 了 基于 
堆 实 现 的 优先 队列 。 


1. 快 速 排 序 





























快速 排序 是 应 用 最 广泛 的 排序 算法 之 一 。 它 的 基本 思想 是 ， 选 择 序列 中 的 一 个 元 素 作为 枢 


























[> 


， 将 小 于 枢 轴 的 元 素 放 在 左边 ， 



























































将 大 于 枢 轴 的 元 素 放 在 右边 ， 针 对 左右 两 个 子 序列 重复 此 过 程 ， 直 到 序列 为 空 或 者 只 剩 下 一 个 元 素 。 









































在 《算法 导论 》 四 一 书 中 ， 给 出 了 一 个 教科 书 式 的 快速 排序 实现 算法 ， 它 的 实现 方法 是 : 选择 序列 的 最 后 一 个 元 素 作为 枢 


























































































































并 使 用 一 个 索引 由 前 往 后 遍历 整个 序列 ， 将 小 于 枢 轴 的 元 素 交换 到 左边 ， 大 于 枢 轴 的 元 素 交 换 到 右边 ， 直 到 序列 为 空 或 者 只 












































































































































































































































































































































剩 下 一 个 元 素 。 

Hadoop 实 现 的 快速 排序 在 该 快速 排序 之 上 进行 了 以 下 优化 。 

C1) 枢 轴 选择 

枢 轴 的 选择 好 坏 直 接 影响 快速 排序 的 性 能 ， 而 最 坏 的 情况 是 划分 过 程 中 始终 产生 两 个 极端 不 对 称 的 子 序列 (有 一 个 长 度 为 
1， 另 一 个 为 -1) ， 此 时 排序 算法 复杂 度 将 增 为 O(N? ) 。 减 小 出 现 划 分 严重 不 对 称 的 可 能 性 ，Hadoop 将 序列 的 首尾 和 中 间 元 
素 中 的 中 位 数 作为 枢 轴 。 

(2) 子 序 列 划 分 方法 

Hadoop 使 用 了 两 个 索引 二 j 分 别 从 左右 两 端 进行 扫描 序列 ， 并 让 索引 六 描 到 大 于 等 于 枢 轴 的 元 素 停 止 ， 索 引 j 扫 描 到 小 于 等 于 
枢 轴 的 元 素 停止 ， 然 后 交换 两 个 元 素 ， 重 复 这 个 过 程 直 到 两 个 索引 相遇 。 

(3) 对 相同 元 素 的 优化 

在 每 次 划分 子 序列 时 ， 将 与 枢 轴 相同 的 元 素 集 中 存放 到 中 间 位 置 ， 让 它们 不 再 参与 后 续 的 递归 处 理 ， 即 将 序列 划分 成 三 部 
分 : 小 于 枢 轴 、 等 于 枢 轴 和 大 于 枢 



























































(4) 减少 递归 次 数 
































当 子 序列 中 元 素数 目 小 于 13 时 ， 直 接 使 用 插入 排序 算法 ， 不 再 继续 递归 。 


2. 优 先 队列 



































文人 








F 归 并 由 类 Merger 完 成 ， 它 要 求 待 排序 对 象 需 是 Segment 实 例 化 对 象 。Segment 是 对 磁盘 和 内 存 中 的 下 je 格式 文件 的 抽象 。 它 


具有 类 似 于 迭代 器 的 功能 ， 可 从 代 读 取 IFike 文 件 中 的 keyvalue。 














Merser 采 用 了 多 轮 递归 合并 的 方式 ， 每 轮 选取 最 小 的 前 io.sort,factor (默认 是 10， 用 户 可 配置 ) 个 文件 进行 合并 ， 并 将 产生 的 
文件 重新 加 入 待 合并 列表 中 ， 直 到 剩 下 的 文件 数目 小 于 io.sort, 包 ctor 个 ， 此 时 ， 它 会 返回 指向 由 这 些 文件 组 成 的 小 顶 堆 的 迭代 器 。 
在 图 8-3 中 ， 我 们 给 出 了 一 个 jo.sort.factor 为 3 的 文件 合并 实例 。 




































map_0.out map_3.out map_4.out map_2.out map_1.out 
map_2.out map_1.out map_6.out 
© insert 
map_5.out map_2.out map_6.out map_1.out map_0.out.merged 










map_5.out.merged 
ONER 各 全 
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如 图 








图 8-3 文件 合并 过 程 


























8-4 所 示 ， 在 每 一 轮 合 并 过 程 中 ，Merger 采 用 了 小 顶 堆 实现 ， 进 而 可 将 文件 合并 过 程 看 作 一 个 不 断 建 堆 的 过 程 ， 建 堆 一 

















取 堆 顶 元 素 一 重新 建 堆 一 取 堆 顶 元 素 .…… 


RawKeyValuelterator 





Segment Segment Segment 


| read + read 
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! read ++ | read ‘read 
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[File IFile IFile IFile IFile 




















图 8-4 利用 小 顶 堆 合 并 文件 
[1] Thomas H. Cormen, Charles E.Leiserson、Ronald L.Rivest. Clifford Stein,“ 算 法 导论 ”， 第 3 版 。 





8.2.3 Reporter 














报 最 新 进度 和 计数 器 值 ， 而 这 了 Reporter? (4 
[ 报 的 信息 中 包含 两 部 分 : 





F 实 现 的 。 在 Map/Reduce Task 
任务 执行 进度 和 任务 计数 


前 几 章 提 到 ， 所 有 Task 需 周期 性 向 TaskTracker 

















[5 
FE 
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mi 


现 了 Reporter 接 口 ， 并 且 以 线程 























中 ，TaskReporter 类 实 
器 值 。 


zk Ji). TaskReporter’| 


1. 任 务 执行 进度 














用 了 简单 的 线性 模型 计算 每 个 阶段 


4 
[J 





任务 执行 进度 信息 被 封装 到 类 Progress 中 ， 且 每 个 Progress 实 例 以 树 的 形式 存在 。Hadoop 采 
的 进度 值 : 如 果 一 个 大 阶段 可 被 分 解 成 若干 个 子 阶段 ， 则 可 将 大 阶段 看 作 一 棵 树 的 父 节 点 ， 而 子 阶段 可 看 作 父 节 点 对 应 的 子 
大 阶段 的 进度 值 可 被 均 摊 到 各 个 子 阶段 中 ;如果 一 个 阶段 不 可 再 分 解 ， 则 该 阶段 进度 值 可 表示 成 已 读 取 数 据 量 占 总 数 
的 比例 。 
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Ha 


点 ， B Fi 


E p 












































对 于 Map Task 而 言 ， 它 作为 一 个 大 阶段 不 可 再 分 解 ， 为 了 简便 ， 我 们 直接 将 已 读 取 数据 量 占 总 数据 量 的 比例 作为 任务 当前 执 


行进 度 值 。 

















E. 























E 务 总 进度 的 1/3。 考虑 到 在 Shuffle 阶 
占 Shuffle 进 度 的 


Reduce, ANE EA 


因此 ， 可 被 分 解 成 M 个 阶段 ， 每 个 阶段 








对 于 Reduce Task 而 言 ， 我 们 可 将 其 分 解 成 三 个 阶段 : Shuffe、Sort 和 
段 ，Reduce Task 需 从 M (M 为 Map Task 数 


1M， 具 体 如 图 8-5 所 示 。 












































) 个 Map Task 上 读 取 一 片 数据 ， 







































1/3 


Reduce 
progress 


1/M 








1/ 


Sort 
progress 
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1/M 


















copy-map 1 
progress 


copy-mapM 
progress 


copy -map 0 
progress 


并 不 会 总 是 每 隔 





8-5 Reduce Task 进度 树 


图 





[ 报 。 





情况 之 一 时 才 会 ; 





一 段 时 间 汇 报 进度 和 计数 器 值 ， 而 是 仅 当 发 现 以 下 两 利 








对 于 TaskReporter 线 程 而 言 ， 











口 任务 执行 进度 发 生变 化 ; 





口 任务 的 某 个 计数 器 值 发 生变 化 。 














在 某 个 时 间 间 隔 内 ， 如 果 任 务 执行 进度 和 计数 器 人 
否 活着 。 在 一 定时 间 内 ， 如 果菜 个 任务 的 执行 进度 和 计数 器 值 均 未 发 和 9 
接 将 其 杀 掉 。 为 了 防止 某 条 记录 因 处 理 时 间 过 长 导致 被 杀 ， 用 户 可 采 月 





均 未 发 生变 化 ， 则 Task 只 会 简单 地 通过 调用 RPC 函 数 ping 探 测 TaskTracker 是 
E 变 化 ， 则 TaskTracker 认 为 它 处 于 悬挂 (hang up) 状态 ， 直 
日 以 下 两 种 方法 : 
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Lo 








仍然 活着 。 





口 每 隔 一 段 时 间 调 








用 一 次 TaskReporter.progress0 函 数 ， 以 告诉 TaskTracker 自 





口 增 大 任务 超时 参数 mapred.task.timeout〈 默 认 是 10 min) 对 应 的 值 。 





2. 任 务 计数 器 


























任务 计数 器 (Counter) 是 Hadoop 提 供 的 ， 用 于 实现 跟踪 任务 运行 进度 的 全 局 计数 功能 。 用 户 可 在 自己 的 应 用 程序 中 添加 计数 
器 。 任 务 计数 器 由 两 部 分 组 成 : <name, value>， 其 中 ，name 表 示 计 数 器 名 称 ，value 表 示 计 数 器 值 〈long 类 型 ) 。 计 数 器 通常 以 组 
为 单位 管理 ， 一 个 计数 器 属于 一 个 计数 器 组 〈CounterGroup) 。 此 外 ，Hadoop 规 定 一 个 作业 最 多 包含 120 个 计数 器 〈 可 通过 参数 
mapreduce.job.counters.limit 设 定 ) ，50 个 计数 器 组 。 


































































































对 于 同一 个 任务 而 言 ， 所 有 任务 包含 的 计数 器 相同 ， 每 个 任务 更 新 自己 的 计数 器 值 ， 然 后 汇报 给 TaskTracker， 并 由 
TaskTracker 通 过 心跳 汇报 给 JobTracker， 最 后 由 JobTracker 以 作业 为 单位 对 所 有 计数 器 进行 累加 。 作 业 的 计数 器 分 为 两 类 ; 
MapReduce 内 置 计数 器 和 用 户 自 定 义 计数 器 。 




























































































(1) MapReduce 内 置 计 数 器 








MapReduce 框 架 内 部 为 每 个 任务 添加 了 三 个 计数 器 组 ， 分 别 位 于 Fike Input Format Counters, File Output Format Counters 和 Map- 
Reduce Framework 中 。 它 们 包含 的 计数 器 分 别 见 表 8-1， 表 8-2 和 表 8-3。 

















表 8-1 File Input Format Counters 中 的 计数 器 


计数 器 含义 
i 


Hi ABH 












计数 器 名 称 
Bytes Read 


计数 器 更 新 
TrackedRecordReader 










表 8-2 File Output Format Counters 中 的 计数 器 


计数 器 名 称 计数 器 含义 计数 器 更 新 
Bytes Written 写 人 文件 系统 的 数据 量 (B) OldTrackingRecordWriter/ 
NewTrackingRecord Writer 





表 8-3 Map-Reduce Framework 中 的 计数 器 





计数 器 名 称 计数 器 含 计数 器 更 新 
Map input bytes Map Task 输入 数据 量 (B) TrackedRecordReader 
Map output records Map Task 输入 记录 条 数 MapOutputBuffer 
Map output bytes Map Task 和 输出 数据 量 (B) MapOutputBuffer 
Map output materialized bytes Map Task 输出 数据 量 (B) MapOutputBuffer 





Map skipped records Map Task 跳 过 坏 记 录 条 数 SkippingRecordReader 
Combine input records Combiner 输入 记录 条 数 MapOutputBuffer 


Combine output records Combiner 输出 记录 条 数 MapOutputBuffer 


Reduce input groups Reduce Task 输入 分 组 数目 runOldReducer/runNewReducer 


( 续 ) 








计数 器 名 称 计数 器 含义 计数 器 更 新 

Reduce shuffle bytes Shuffle 数据 量 (B) MapOutputCopier 

Reduce input records Reduce Task 输入 记录 条 runOldReducer/runNewReducer 

Reduce output records Reduce Task 输出 记录 条 数 OldTrackingRecordWriter/ 
NewTrackingRecord Writer 

Reduce skipped records Reduce Task kit Hic at Re SkippingReduce Valueslterator 

Reduce skipped groups SkippingReduce ValuesIterator 

Spilled Records BUKAK MapOutputBuffer 

Total committed heap usage (bytes) TaskReporter 

CPU time spent (ms) 耗费 CPU 时 间 TaskReporter 

Physical memory (bytes) snapshot 耗费 物理 内 存量 TaskReporter 





Virtual memory (bytes) snapshot 耗费 虚拟 内 存量 TaskReporter 


(2) 用 户 自 定义 计数 器 











不 同 的 编程 接口 ， 定 义 计 数 器 的 方式 不 同 。 接 下 来 ， 我 们 简要 介绍 Java、Hadoop Pipes 和 Hadoop Streaming 中 定义 计数 器 的 方 
法 。 








Java 





























Hadoop 为 Java 应 用 程序 提供 了 两 种 访问 和 使 用 计数 器 的 方式 ， 使 用 枚 举 类 型 和 字符 串 类 型 。 如 果 采 用 枚 举 类 型 ， 则 计数 器 默 
认 名 称 是 枚 举 类 型 的 Java 完 全 限定 类 名 ， 这 使 得 计数 器 名 称 的 可 性 读 性 很 差 ， 为 此 ，Hadoop 提 供 了 基于 资源 捆绑 修改 计数 器 显示 
名 称 的 方法 : 以 Java 枚 举 类 型 为 名 称 创建 一 个 属性 文件 。 在 该 属性 文件 中 ，“CounterGroupName” 属 性 用 于 设 定 整个 组 的 显示 名 称 ， 
而 枚 举 类 型 中 每 个 字段 均 有 一 个 属性 与 之 对 应 ， 属 性 名 称 为 “字段 类 型 .name” 属性 值 即 为 该 计数 器 的 显示 名 称 。 比 如 ， 类 Task 中 
定义 了 大 量 表示 计数 器 的 枚 举 类 型 ， 而 这 些 计数 器 的 显示 名 称 被 统一 放 到 同 目 录 下 的 属性 文件 Task_Counter.properties 中 ， 且 内 容 如 
下 : 



















































































CounterGroupName= 
Map-Reduce Framework 
MAP INPUT RECORDS .name= 
Map input records 
MAP_INPUT BYTES.name= 
Map input bytes 

MAP OUTPUT RECORDS.name= 
Map output records 

MAP OUTPUT BYTES.name= 
Map output bytes 
































如 果 采 用 字符 串 类 型 ， 则 用 户 可 以 直接 在 计数 器 API 中 指定 计数 器 组 ， 计 数 器 名 称 和 计数 器 值 。 基 于 枚 举 类 型 和 字符 串 类 型 的 
计数 器 API 如 下 : 
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public abstract void incrCounter (Enum<?>key, long amount) ; 
public abstract void incrCounter (String group, String counter, long amount) ; 





Hadoop Pipes 

















Hadoop Pipes 提 供 了 一 套 基 于 字符 串 类 型 的 计数 器 API。 通 常 使 用 一 个 计数 器 需 分 成 三 步 ， 分 别 是 定义 、 注 册 和 使 用 ， 举 例如 
“Ps 























Penn] 











HadoopPipes: TaskContext: Counter*mapCounter; // 定 义 
mapCounter=context.getCounter ("counterGroup", "mapCounter") ; // 注 册 





context.incrementCounter (mapCounter，1) ; // 使 























Hadoop Streaming 


EN 











前 面 提 到 ，Hadoop Streaming 基 于 标准 输入 输出 机 种 
输入 流 、 标 准 输出 流 和 标准 错误 输出 流 ， 其 中 前 两 个 主要 用 于 输入 输出 数据 ， 第 三 种 则 用 于 向 Java 端 














— 











可 支持 多 种 语言 编写 MapReduce 程 序 ， 而 标准 输入 输出 流 包含 三 种 : 标准 
























































数 器 值 、 任 务 状态 等 。 如 果 月 























户 发 送 计 数 器 值 ， 则 可 使 用 标准 错误 输出 流 输出 以 下 字符 串 : 


传递 任务 运行 状态 ， 包 括 计 





reporter: counter: <gr 


oup>, <counter>, <amount> 

















比如 ， 使 用 C 语 言 可 使 用 








以 下 程序 段 增加 计数 器 值 : 








cerr<<"reporter: coun 


ter: counterGroup, mapCounter, 1" 





8.3 Map Task 内 部 实现 





和 Job-cle 


创建 











主要 


8.3.1 


pss 


数据 写 入 本 地 磁盘 之 前 ， 先 要 对 数据 进行 一 次 本 地 排序 ， 并 在 必 











前 面 提 到 ，Map Task 分 为 4 种 ， 分 别 是 Job-setup Task. Job-cleanup Task, Task-cleanup Task 和 Map Task。 其 中 ，Job-setup Task 











和 删除 作 、 








讲解 第 四 种 任务 一 一 普通 的 Map Tasko 





口 Map 阶 段 : 该 阶段 主 














Map Task 的 整体 计算 流程 如 图 


口 Read 阶 段 ，Map Task 通 过 月 


anup Task 分 别 是 作业 运行 时 启动 的 第 


Map Task 整 体 流程 





8-6 所 示 ， 内 








> SS TER 
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bine 


























Q Collecti Bt: 在 用 户 编写 的 map0O 函 数 
它 会 将 生成 的 key/value 分 片 ( 通 











过 调 月 








个 任务 和 最 后 一 个 任务 ， 主 要 了 
临时 输出 目录 ; 而 Task-cleanup Task 则 是 任务 失败 或 者 被 杀 死 后 ， 用 了 
数据 ， 并 将 计算 结果 存 到 本 地 磁盘 | 








分 为 5 个 阶段 ， 分 别 是 : 


户 编 写 的 RecordReader， 从 输入 InputSptt 中 解析 蝇 
































口 Sp 训 价 段 : Bat”, 


口 Conbine 阶 段 : 当 所 有 数据 处 理 


当 环 


























InputSplit 


Read 


MapReduce 框 架 提供 了 两 套 API， 默 认 情 况 下 采 








HPartitioner) ， 并 写 入 一 个 环 姑 


PRIX WA MapReduce H žr 























Ph， 当 数据 处 理 完成 后 ， 一 般 会 调 




















Partition 
Collect 


Map 
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Collect 





居 写 到 本 地 磁盘 上 ， 
要 时 对 数据 进行 合并 、 














Memory Buffer 


Sort 
[Combine] 
[Compress] 


8-6 Map Task 计 算 流程 

















Spill 






































[ 作 分 别 是 进行 一 些 作业 初始 化 和 收 
F 清理 已 写 入 临时 目 











一 个 个 key/value。 





用 OutputCollector.collect0 输 出 结 
内 存 缓冲 区 中 。 

生成 一 个 临时 文件 。 
压缩 等 操作 。 

















merge 





Combine 


API， 用 户 可 通过 设置 参数 mapred.mapper.new-api 为 true 启 


在 封装 性 和 扩展 性 等 方面 优 于 旧 API， 但 性 能 上 并 没有 改进 。 本 章 主要 以 旧 API 为 例 进 行 讲解 。 























在 Map Task 中 ， 





pail 
Lim, 
wen) 
et 











出 结果 在 内 存 和 磁盘 中 的 组 织 方式 ， 


























人体 涉及 Collect、Spil 和 Conibine 三 个 阶段 ， 也 就 是 用 








尾 工作 ， 比 如 


录 中 数据 的 任务 。 本 节 


要 是 将 解析 出 的 key/value 交 给 用 户 编 写 的 map0 函 数 处 理 ， 并 产生 一 系列 新 的 key/value。 





果 。 在 该 函数 内 





完成 后 ，Map Task 对 所 有 临时 文件 进行 一 次 合并 ， 以 确保 最 终 只 会 生成 一 个 数据 文件 。 




















新 API。 新 API 




















户 调 























] OutputCollector.collect0 函 数 之 后 依次 经 历 的 几 个 阶段 。 我 们 将 在 下 硬 














几 小 节 深 入 分 析 这 几 个 阶段 。 


8.3.2 ”Collect 过 程 分 析 











实现 机 制 。 














跟踪 进入 Map Task 的 入 
建 合 适 的 MapRunnable 以 迭代 调 


象 。 


OldOutputCollector 根 和 
DirectMapOutputCollector 对 
Task 进 一 步 处 理 。 本 小 节 主 























MapOutputBuffer 内 部 使 用 了 一 个 缓冲 区 暂时 存储 / 
响 到 Map Task 的 写 效率 ， 而 现 有 多 种 数 


数据 缓冲 
写 入 输出 ， 


pier ae 
局 ， 不 能 
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当 缓 冲 











种 更 好 的 缓冲 








用 户 在 map0 函 数 


区 号 partition， 然 后 将 三 元 组 


区 的 设计 方式 直接 
区 写 满 后 ， 一 次 性 写 到 磁盘 上 ， 
持 同 时 读 写 数据 。 双 缓冲 
写 到 磁盘 上 ， 这 样 ， 两 个 缓冲 区 交 蔡 读 写 ， 进 f 





新 的 keyvalue 后 ， 会 





Ea 
加 























数 run0， 可 发 现 ， 如 果 用 














Pye 
































用 户 编写 的 mapO 函 数 ， 





可 
ea 








象 直接 将 结果 写 入 HDFS 中 作为 





























ba 








EY, 
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最 终结 


要 分 析 Reduce Task 数 目 非 0 的 情况 。 
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输出 数据 ， 














就 这 样 





JIHAPI, Wy 
和 mapO 函 数 的 参数 OutputCollectorj 


当 缓 冲 





E 
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HH OldOutputCollector.collect (key, value) 后 ， 在 该 函数 内 部 ， 首 先 会 调 ) 
|<key, value, partition> {%3% %3 MapOutputBuffèr.collect() 


数 做 进一步 处 








区 使 | 












































区 是 对 单 向 缓冲 区 的 


个 改进 

















区 设计 方式 是 采用 环 
增加 的 剩余 空间 中 循环 写 入 数据 ， 进 而 达到 真正 的 读 写 











x: 


i 提高 效率 。 实 际 .J 








， 它 使 | 
上 ， 双 组 六 








两 个 缓冲 区 ， 
PX 
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只 能 


用 OutputCollector.collect0 函 数 输 出 结 


用 runOldMapper 函 数 处 至 


昌 作 业 是 否 包含 Reduce Task 封 装 了 不 同 的 MapOutputCollector 实 现 ， 如 果 Reduce Task 数 
果 ， 否 则 封装 MapOutputBuf 人 Rr 对 象 暂时 将 结果 写 入 本 地 磁盘 上 以 供 Reduce 




















。 本 小 节 重 点 















































] 率 达到 一 定 阐 值 后 ， 青 将 绥 冲 
据 结 构 可 供 选 择 ， 最 简单 的 是 单 向 缓冲 
， 不 断 写 缓冲 区 ， 直 到 所 有 数据 写 到 磁盘 上 。 单 向 缓 六 
中 一 个 用 于 写 入 数 提 
一 定 程度 上 让 读 写 





区 中 的 








区 ， 


























行 ， 仍 会 存在 








生产 者 向 缓冲 
区 最 大 的 问题 是 性 
io J~ 


‘v yt 


wes 


剖析 该 函数 内 部 


数据 。 该 函数 根据 实际 的 配置 创 
FE 是 MapRunnable 传 入 的 OldOutputCollector 对 


为 0， 则 封装 

















Partitioner.getPartition0) 函 数 获 取 记 录 的 分 


数据 写 到 磁盘 上 。 


中 单 向 





x 








个 将 写 满 的 数据 


等 待 问 题 。 

















缓冲 








当 缓 冲 区 使 用 率 达 到 











行 。 三 种 缓冲 区 结构 如 











read/write 





MapOutputBufRr 正 是 采用 了 环形 内 存 组 六 


所 有 数据 处 


























MapOutputBuffer 内 部 采用 了 两 级 索引 结构 ( 见 
区 所 占 内 存 空间 总 大 小 为 io.sort.-mb 默认 是 100 MB) 。 下 
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read 





b) 








KI 


8-7 





EREE, 1E 


三 种 缓冲 














图 8-7 所 示 。 


write 





区 结构 





a) 单 向 缓冲 
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区 保存 数据 站 ， 
理 完毕 后 ， 对 所 有 临时 文件 进行 一 次 合 


x] 


b) MÆ 
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c) 循环 缓冲 区 














当 x 


当 缓 冲 区 
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8-8) ， 涉 及 三 个 环形 内 存 组 六 
分 别 介绍 这 三 个 缓冲 








] 率 达到 一 定 闵 值 后 ， 


开始 向 磁盘 上 写 入 数据 ， 同 时 ， 生 ) 














线程 SpilThread 将 数 和 


























区 的 含义 。 


生成 一 个 最 终 文件 。 环 形 缓冲 区 


者 仍 可 以 向 不 断 


read&write 


居 写 到 一 个 临时 文 








使 得 Map Task 的 Collect 


阶段 和 Spii 阶 段 可 


Ph 区 ， 分 别 是 kvoffsets、kvindices 和 kvbufer， 这 三 个 缓冲 






kvindiceg } 


kvbuffer{] 


8-8 ”MapOutputBuffer 的 两 级 索引 结构 


(1) kvoffsets 






































kvoffets 即 偏 移 量 索 引 数 组 ， 用 于 保存 key/vValue 信 息 在 位 置 索引 kvindices 中 的 偏 移 量 。 考 虑 到 一 对 key/value 需 占用 数组 kvo 从 ets 的 1 个 
int( 整 型 ， 大 小 ， 数 组 kvindices 的 3 个 jnt 大 小 (分 别 保存 所 在 partition 号 、key 开 始 位 置 和 value 开 始 位 置 ) ， 所 以 Hadoop 按 比例 1: 3 将 大 小 为 
$ {io.sort.record.percent} *${io.sort.nmb} 的 内 存 空 间 分 配给 数组 kvoffsets 和 kvindices， 其 间 涉 及 的 缓冲 区 分 配方 式 见 图 8-9， 计 算 过 程 如 下 : 





















































= 














private static final int ACCTSIZE=3; // 每 对 key/value 占 用 kvindices 中 的 三 
private static final int RECSIZE= (ACCTSIZE+1) *4; // 每 对 key/value 共 占 
kvoffsets 和 kvindices 中 的 4 个 字 节 (4*4=16 byte) 

final float recper=job.getFloat ("io.sort.record.percent", (float) 0.05) ; 
final int sortmb=job.getInt ("io.sort.mb", 100) ; 

int maxMemUsage=sortmb<<20; // 将 内 存单 位 转化 为 字 节 

int recordCapacity= (int) (maxMemUsage*recper) ; 
recordCapacity-=recordCapacity%RECSIZE; // 保 证 recordCapacity 是 4*4 的 整数 倍 
recordCapacity/=RECSIZE; // 计 算 内 存 中 最 多 保存 key/value 数 
kvoffsets=new int[recordCapacity]; //kvoffsets 占 用 1: 3 中 的 1 
kvindices=new int[recordCapacity*ACCTSIZE]; //kvindices 占 用 1: 3 中 的 3 





































































































当 该 数组 使 用 率 超 过 io.sort,sp 记 percent 后 ， 便 会 触发 线程 SpilThread 将 数据 写 入 磁盘 。 


(2) kvindices 





























kvindices 即 位 置 索引 数组 ， 用 于 保存 keyvalue 值 在 数据 缓冲 区 kvbufer 中 的 起 始 位 置 。 

















(3) kvbuffer 









































kvbufRr 即 数据 缓冲 区 ， 用 于 保存 实际 的 keyvalue 值 ， 默 认 情 况 下 最 多 可 使 用 io.sortmb 中 的 93%， 当 该 缓冲 区 使 用 率 超 过 
io.sortsp 记 percent 后 ， 便 会 触发 线程 SpitThread 将 数据 写 入 磁盘 。 











kvbuffer 
= new byte 100<<20-—(100<<20)*5% | 


ACCTSIZE = 3 
RECSIZE =(ACCTSIZE + 1)* 4 
recordCapacity=((100<<20) * 5%\V/RECSIZE 


kvoffsets 
=new int[recordCapacity] 


kvindices= 
new int[recordCapacity* ACCTSIZE] 


io.sort.mb = 100 MB 











图 8-9 ”内 存 jo.sort.nb 的 分 配方 式 

































































以 上 几 个 缓冲 区 读 写 采用 了 典型 的 单 生产 者 消费 者 模型 ， 其 中 ，MapOutputBufer 的 collect 方 法 和 MapOutputBuffer.Bufer 的 write 方 法 是 生 
产 者 ，spilThread 线 程 是 消费 者 ， 它 们 之 间 同 步 是 通过 可 重 入 的 互 斥 锁 spillLock 和 spillLock 上 的 两 个 条 件 变量 (spilDone 和 spillReady〉 完 成 
的 。 生 产 者 主要 的 伪 代 码 如 下 : 












































// 取 得 下 一 个 可 写 入 的 位 置 
spillLock.lock(); 

if (Ser x ERIK SIE) { 

// 唤 醒 Spil1Thread 线 程 ， 将 缓冲 区 数据 写 入 磁盘 
spillReady.signal (); 





























} 

if (Sap) { 

/ /等待 Spill1Threag 线 程 结束 
spillDone.wait (); 

} 

spillLock.1lock (); 

// 将 数据 写 入 缓冲 区 





























下 面 分 别 介绍 环形 缓冲 区 kvo 信 ets 和 kvbufRr 的 数据 写 入 过 程 。 








(1) 环形 缓冲 区 kvofRets 





















































通常 用 一 个 线性 缓冲 区 模拟 实现 环形 缓冲 区 ， 并 通过 取 模 操作 实现 循环 数据 存储 。 下 面 介 绍 环形 缓冲 区 kvofRets 的 写 数据 过 程 。 该 过 
程 由 指针 kvstarykvend/kvindex 控 制 ， 其 中 kvstart 表 示 存 有 数据 的 内 存 段 初始 位 置 ，kvindex 表 示 未 存储 数据 的 内 存 段 初始 位 置 ， 而 在 正常 写 
入 情况 下 ，kvend=kvstart， 一 旦 满足 溢 写 条 件 ， 则 kvend=kvindex， 此 时 指针 区 间 [kvstart, kvend〉 为 有 效 数据 区 间 。 具 体 涉及 的 操作 如 下 。 























































































































BEL: 写 入 缓冲 区 。 











直接 将 数据 写 入 kvindex 指 针 指向 的 内 存 空间 ， 同 时 移动 kvindex 指 向 下 一 个 可 写 入 的 内 存 空间 首 地 址 ，kvindex 移 动 公式 为 : 
kvindex= (kvindext1) %kvofRSets.jength。 由 于 kvofkets 为 环形 缓冲 区 ， 因 此 可 能 涉及 两 种 写 入 情况 。 










































































=> 
z 
yp. 





情况 1: kvindex>kvend， 如 图 8-10 所 示 。 在 这 种 情况 下 ， 指 针 Jvindex 在 指针 kvend 后 面 ， 如 果 向 缓冲 区 中 写 入 一 个 字条 
指针 后 移 一 位 。 























BAR: 


kvstart, kvend kvindex 


kvstart,.kvend kvindex 





图 8-10 环形 缓冲 区 在 kvindex>kvend 情 况 下 写 入 数据 























人 从属 hp 中 


情况 2，kvindex<<=kvend， 如 图 8-11 所 示 。 在 这 种 情况 下， 指针 kvindex 位 于 指针 kvend 前 面 ， 如 果 向 缓冲 区 中 写 入 一 个 字符 串 ， 则 
kvindex 指 针 后 移 一 位 。 



































Ej ARI 

kvindex kvstart ,kvend 
BAR 

kvindex kvstart ,.kvend 


8-11 环形 缓冲 区 在 kvindex<=kvend 情 况 下 写 入 数据 





操作 2: 溢 写 到 磁盘 。 











当 kvoffsets 内 存 空间 使 用 率 超 过 io.sort.sp 筷 percent〔 默 认 是 80%) 后 ， 需 将 内 存 中 数据 写 到 磁盘 上 。 为 了 判断 是 否 满足 该 条 件 ， 需 先 求 
出 kvoffsets 已 使 用 内 存 。 如 果 kvindexkvend， 则 已 使 用 内 存 大 小 为 kvindex-kvend; 和 否则， 已 使 用 内 存 大 小 为 kvo 人 ets.length- 〈kvend- 
























































kvindex) 。 


(2) 环形 缓冲 区 kvbuffr 
































环形 缓冲 区 kvbu 人 rt 的 读 写 操 作 过 程 由 指针 bufstart/bufend/bufvoid/bufindex/bufimark 控 制 ， 其 中 ，bufstart/bufend/bufindex 含 义 与 
kvstartkvend/kvindex 相 同 ， 而 bufvoid 指 向 kvbufier 中 有 效 内 存 结束 为 止 ，kvbuffer 表 示 最 后 写 入 的 一 个 完整 key/value 结 束 位 置 ， 具 体 写 入 过 程 
中 涉及 的 状态 和 操作 如 下 : 



































情况 1: 初始 状态 。 











初始 状态 下 ，bufstart=bufend=bufindex=bufimark=0，bufvoid=kvbuffer.length， 如 图 8-12 所 示 。 


a 


A 
bufvoid 


图 8-12 初始 状态 下 的 kvbuffer 





情况 2: 写 入 一 个 key。 


























写 入 一 个 key 后 ， 需 移动 bufindex 指 针 到 可 写 入 内 存 初 始 位 置 ， 如 图 8-13 所 示 。 


A 
bufvoid 


A A 
bufstart 
iferd bufindex 


bufmark 





图 8-13 向 kvbufRr 中 写 入 一 个 key 


情况 3: 写 入 一 个 value。 
写 入 key 对 应 的 value 后 ， 除 移动 bufindex 指 针 外 ， 还 要 移动 bufmark 指 针 ， 表 示 已 经 写 入 一 个 完整 的 keyvalue， 有 具体 如 


Ed 


à bufind 
bufstart ulindex 
bufend bufmark bufvoid 


图 8-14 所 示 。 














8-14 ”向 kvbufer 中 写 入 一 个 value 


情况 4: 不 断 写 入 keyvalue， 直 到 满足 溢 写 条 件 ， 即 kvo 人 ets 或 者 kvbufRer 空 间 使 用 率 超 过 io.sortspiLpercent 〈 默 认 值 为 80%) 。 此 时 需要 


将 数据 写 到 磁盘 上 ， 如 图 8-15 所 示 。 


>=80% 
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a A 
bufstart bufindex bufvoid 
bufmark 








图 8-15 kvbuffer(s H KiS FIRE 





情况 5: iit o 








体 如 图 8-16 所 示 。 

















将 缓冲 区 [bufstart bufend) 之 间 的 数据 写 到 磁盘 上 ， 




















如 果 达 到 溢 写 条 件 ， 则 令 bufende-bufindex， 


A “A 
bufindex bufvoid 


A 
bufstart bufmark 
bufend 





8-16 准备 开始 溢 写 

















图 8-17 所 示 。 





洲 写 完成 之 后 ， 恢 复 正常 写 入 状态 ， 令 bufstarte-bufend， 如 


ee 











A A 
bufstart ; 
bofin bufvoid 
bufmark 
bufend 
图 8-17 RIER 
在 溢 写 的 同时 ，Map Task 仍 可 向 kvbufRr 中 写 入 数据 ， 如 图 8-18 所 示 。 
Spill to Disk Newly Written 
一 人 C 
A A A A 
0 bufstart bufend bufindex 
bufmark 





图 8-18 溢 写 的 同时 ， 被 写 入 新 数据 











情况 6: 写 入 key 时 ， 发 生 跨 界 现 象 。 
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当 写 入 某 个 key 时 ， 组 冲 区 尾部 剩余 空间 不 足以 容纳 整个 key 值 ， 此 时 需要 将 key 值 分 开 存储 ， 其 中 一 部 分 存 到 缓冲 区 末尾 ， 另 外 一 部 
分 存 到 缓冲 区 首部 ， 有 具体 如 图 8-19 所 示 。 


L_l )=—rr 


A A A “A A 
0 bufindex bufstart bufmark bufvoid 
bufend 









































图 8-19 写 入 key 时 ， 发 生 越界 





情况 7: 调整 key 人 位置， 防止 key 跨 界 现象 。 




































































于 key 是 排序 的 关键 字 ， 通 常 需 交 给 RawComparator 进 行 排序 ， 而 它 要 求 排序 关键 字 必 须 在 内 存 中 连续 存储 ， 因 此 不 允许 key 跨 界 存 
储 。 为 解决 该 问题 ，Hadoop 将 跨 界 的 key 值 重新 存储 到 缓冲 区 的 首位 置 ， 通 常 可 分 为 以 下 两 种 情况 。 









































Obufindex+ (bufyoid-bufimark〉 天 bufstart， 此 时 缓冲 区 前 半 段 有 足够 的 空间 容纳 整个 key 值 ， 因 此 可 通过 两 次 内 存 复制 解决 跨行 问题 ， 
具体 如 图 8-20 所 示 。 

















int headbytelen=bufvoid-bufmark; 
System.arraycopy (kvbuffer, 0, kvbuffer, headbytelen, bufindex) ; 
System.arraycopy (kvbuffer, bufvoid, kvbuffer, 0, headbytelen) ; 








mde A A 
0 bufindex bufstart bufmark 
bufend bufvoid 











8-20 调整 位 置 ， 避 免 key 跨 界 
































Dbufindexr (bufvoid-bufimark) 之 =buftart， 此 时 缓冲 区 前 半 段 没有 足够 的 空间 容纳 整个 key 值 ， 将 key 值 移 到 缓冲 区 开始 位 置 时 将 触发 
一 次 Spil 操 作 。 这 种 情况 下 ， 可 通过 三 次 内 存 复 制 解决 跨行 问题 : 











byte[]keytmp=new byte [bufindex]; // 申 请 一 个 临时 缓冲 区 
System.arraycopy (kvbuffer, 0, keytmp, 0, bufindex) ; 
bufindex=0; 
out.write (kvbuffer, bufmark, headbytelen) ; // 将 key 值 写 入 缓冲 区 开始 位 置 























out .write (keytmp) ; 





情况 8: 某 个 key 或 者 value 太 大 ， 以 至 于 整个 缓冲 区 不 能 容纳 它 。 








如 果 一 条 记录 的 key 或 value 太 大 ， 整 个 缓冲 区 都 不 能 容纳 它 ， 则 Map Task 会 抛 出 MapBufferTooSmallException 异 常 ， 并 将 该 记录 单独 输出 


到 一 个 文件 中 。 








(3) 环形 缓冲 区 优化 






































在 Hadoop 1.X 版 本 中 ， 当 满足 以 下 两 个 条 件 之 一 时 ，Map Task 会 发 生 溢 写 现象 。 














条 件 1: 缓冲 区 kvindices 或 者 kvbufRxr 的 空间 使 用 率 达 到 io.sort,sp 记 percent〈 默 认 值 为 80%) 。 














条 件 2: 出 现 一 条 kvbuffer 无 法 容纳 的 超大 记录 。 








前 面 提 到 ，Map Task 将 可 用 的 缓冲 区 
和 kvbufRr 三 个 组 六 


Wk A, KRAH 



































key/valuex} ) 需 占 























Ph 区 ， 而 正如 条 件 1 所 述 ， 
































空间 io.sortmb 按 照 一 定 比例 〈 由 参数 jo.sortrecord.percent 决 定 ) 静态 分 配给 了 kvoffsets、kvindices 
只 要 任何 一 个 缓冲 区 的 使 用 率 达 到 一 定 比例 ， 就 会 发 生 溢 写 现象 ， 即 使 男 外 的 缓冲 区 使 用 率 非 






























































EE 的 io.sort.record.percent 参 数 ， 对 于 充分 利用 缓冲 区 空间 和 减少 涪 写 次 数 ， 是 十 分 必要 的 。 考 虑 到 每 条 数据 (一 个 
































用 索引 大 小 为 16 B， 因 此 ， 建 议 用 户 采用 以 下 公式 中 设置 jo.sort.record.percent: 


io.sort.record.percent=16/ (16+R) 


其 中 R 为 平均 每 条 记录 的 长 度 。 











【实例 】 假 设 一 个 作业 的 Map Task 输 入 数据 量 和 输出 数据 量 相 同 ， 每 个 Map Task 输 入 数据 量 大 小 为 128 MB， 且 共有 1 342 177 条 记 
录 ， 每 条 记录 大 小 约 为 100 B， 则 需要 索引 大 小 为 16*1 342 177=20.9 MB。 根 据 这 些 信息 ， 可 设置 参数 如 下 : 


Uio. sort.mb: 


















































128 MB+20.9 MB=148.9 MB 


口 io. sort.record.percent: 16/ (16+100) =0.138 


口 io. sort.spillpercent: 1.0 























这 样 配置 可 保证 数据 只 “ 纱 ” 一 次 地 ， 效 率 最 高 ! 当然 ， 实 际 使 用 时 可 能 很 难 达 到 这 种 情况 ， 比 如 每 个 Map Task 输 出 数据 量 非常 大 ， 绥 








冲 区 难以 全 部 容纳 

















它们 ， 但 你 至 少 可 以 设 















































合理 的 io.sortrecord.percent 以 更 充分 地 利用 io.sortmb 并 尽 可 能 减少 中 间 文 件数 





















































尽管 用 户 可 通 




















过 该 经 验 公式 设置 一 个 较 优 的 io.sort.record.percent 参 数 ， 但 在 实际 应 用 中 ， 估 算 一 个 非常 合理 的 R 值 仍 是 较 麻烦 的 。 为 


























了 从 根本 上 解决 这 个 问题 ，Hadoop 0.21 采 用 共享 环形 缓冲 区 对 Map Task 输 出 数据 的 组 织 方式 进行 了 优化 ， 这 样 ， 用 户 无 须 再 为 自己 的 作 



































业 设 置 io.sortrecord.percent 参 数 。 如 图 8-21 





























所 示 ，Hadoop 0.21 主 要 有 两 个 修改 点 D : 








口 不 再 将 索引 和 记录 分 放 到 不 同 的 环形 缓冲 区 中 ， 而 是 让 它们 共用 一 个 环形 缓冲 区 。 





















































口 引 入 一 个 新 的 指针 equator。 该 指针 界定 了 索引 和 数据 的 共同 起 始 存放 位 置 。 从 该 位 置 开始 ， 索 引 和 数据 分 别 沿 相反 的 方向 增长 内 














存 使 用 空间 。 






































通过 让 索引 和 记录 共享 一 个 环形 缓冲 


























能 够 最 大 限度 地 利用 io.sort.nb 空 间 ， 进 而 》 


























区 ， 可 舍弃 io.sort.record.percent 参 数 ， 这 样 ， 不 仅 解 决 了 用 户 设 置 参 数 的 苦恼 ， 也 使 得 Map Task 
成 少 磁盘 溢 写 次 数 ， 提 高 效率 。 





equator 
Meta Extension 


Records Extension 





me mm | 





16 byte(4 integers) 





kvbuffer(io.sort.mb) 


图 8-21 Hadoop 0.21 中 Map Task 的 环形 缓冲 



































[1] Hadoop 也 曾 采 用 过 双 绥 冲 区 ， 
[2] Todd Lipcon, Cloudera, “Optimiziong MapReduce Job Performance”, Hadoop Summit 2012. 
[3] https//issues. apache. org/jira/browse/ MAPREDUCE-64 

















区 结 


构 


L 体 可 参考 : httpsVissues.apache.orgyjira/browse/HADOOP-1965。 


8.3.3 ”Sp 记过 程 分 析 











Sp 记过 程 由 SpilThread 线 程 完成 。 在 前 一 小 节 中 已 经 提 到 ，SpilfThread 线 程 实际 上 是 缓冲 区 kvbufer 的 消费 者 ， 其 主要 代码 如 
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spillLock.lock(); 

while (true) { 
spillDone.signal (); 
while (kvstart==kvend) { 
spillReady.await(); 

} 
spillLock.unloc 














I k(); 
sortAndSpill(); // 排 序 ， 然 后 将 缓冲 区 kvbuffer 中 的 数据 写 到 磁盘 上 


spillLock.lock(); 

// 重 置 各 个 指针 ， 以 便 为 下 一 次 溢 写 做 准备 

if (bufend<bufindex& &bufindex<bufstart) { 
bufvoid=kvbuffer. length; 

} 

vstart=kvend; 

bufstart=bufend; 





} 
spillLock.unlock (); 








线程 SpilThread 调 用 函数 sortAndSpil0 将 环形 缓冲 区 kvbufer 中 
部 工作 流程 如 下 : 






































步骤 1 利用 快速 排序 算法 对 缓冲 区 kvbufRr 中 区 间 [buftart bufend) PY HY 24 











区 间 [bufstart bufend) Py iy ad 























进行 排序 ， 然 后 按照 Key 进行 排序 。 这 样 ， 经 过 排序 后 ， 数 据 以 分 区 为 单位 聚集 在 一 起 ， 且 同 


























居 写 到 磁盘 上 。 函 数 sortAndSpil0 内 


中 进行 排序 ， 排 序 方式 是 ， 先 按照 分 区 编号 partition 





一 分 区 内 所 有 数据 按照 key 有 序 。 





步骤 2 按照 分 区 编号 由 小 到 大 依次 将 每 个 分 区 中 的 数据 写 入 任务 工作 目录 下 的 临时 文件 output/spilIN.out(N 表 示 当 前 溢 写 次 















































数 ) 中 。 如 果 用 户 设置 了 Conbiner， 则 写 入 文件 之 前 ， 对 每 个 分 























区 中 的 数据 进行 一 次 聚集 





che 





PELE 











步骤 3 将 分 区 数据 的 元 信息 写 到 内 存 索引 数据 结构 SpitRecord 中 ， 其 中 每 个 分 区 的 元 信息 包括 在 临时 文件 中 的 偏 移 量 、 压 缩 





前 数据 大 小 和 压缩 后 数据 大 小 。 如 果 当 前 内 存 中 索引 大 小 超过 1 MB， 则 将 内 存 索引 写 到 文件 








Foutput/spilIN.out.index' 。 











8.3.4 ”Combine 过 程 分 析 








当 所 有 数据 处 理 完 后 ，Map Task 会 将 所 有 临时 文件 合并 成 一 个 大 文件 ， 并 保存 到 文件 output/file.out 中 ， 同 时 生成 相应 的 索引 
文件 output/file.out.index。 




















在 进行 文件 合并 过 程 中 ，Map Task 以 分 区 为 单位 进行 合并 。 对 于 某 个 分 区 ， 它 将 采用 多 轮 递 归 合 并 的 方式 ， 每 轮 合 3 
io.sort.factor 默认 为 100) 个 文件 ， 并 将 产生 的 文件 重新 加 入 待 合 并 列表 中 ， 对 文件 排序 后 ， 重 复 以 上 过 程 ， 直 到 最 终 得 到 一 个 
大 文件 。 











































































































让 每 个 Map Task 最 终 只 生成 一 个 数据 文件 ， 可 避免 同时 打开 大 量 文件 和 同时 读 取 大 量 小 文件 产生 的 随机 读 取 带 来 的 开销 站 





<t 


tin 











[1] https/Assues. apache.org/jira/browse/HADOOP-331 


8.4 Reduce Task 内 部 实现 


与 Map Task 一 样 ，Reduce Task 也 分 为 四 种 ， 即 Job-setup Task, Job-cleanup Task, Task-cleanup Task 和 Reduce Task。 本 节 中 重点 介绍 第 四 


种 普通 Reduce Task. 





























Reduce Task 要 从 各 个 Map Task 上 读 取 一 片 数据 ， 经 排序 后 ， 以 组 为 单位 交 给 用 户 编 写 的 reduce0) 函 数 处理 ， 并 将 结果 写 到 HDFS 上 。 
本 节 将 深入 剖析 Reduce Task 内 部 各 个 阶段 的 实现 原理 。 

















8.4.1 Reduce Task 整体 流程 





Reduce Task 的 整体 计算 流程 如 图 8-22 所 示 ， 共 分 为 5 个 阶段 。 








口 Shufie 阶 段 : 也 称 为 Copy 阶 段 。Reduce Task 从 各 个 Map Task 上 远程 拷贝 一 片 数 据 ， 并 针对 某 一 片 数据 ， 如 果 其 大 小 超过 一 定 国 
值 ， 则 写 到 磁盘 上 ， 否 则 直接 放 到 内 存 中 。 




















SN 


n> 






































口 Merge 阶 段 : 在 远程 拷贝 数据 的 同时 ，Reduce Task 启 动 了 两 个 后 台 线 程 对 内 存 和 磁盘 上 的 文件 进行 
磁盘 上 文件 过 多 。 


并 ， 以 防止 内 存 使 用 过 多 或 























口 Sort 阶 段 : 按照 MapReduce 语 义 ， 用 户 编写 的 reduce0 函 数 输入 数据 是 按 key 进 行 聚集 的 一 组 数据 。 为 了 将 key 相 同 的 数据 聚 在 一 
起 ，Hadoop 采 用 了 基于 排序 的 策略 。 由 于 各 个 Map Task 已 经 实现 对 自己 的 处 理 结果 进行 了 局 部 排序 ， 因 此 ，Reduce Task 只 需 对 所 有 数 
据 进行 一 次 归并 排序 即 可 。 

























































































口 Reduce 阶 段 : 在 该 阶段 中 ，Reduce Task 将 每 组 数据 依次 交 给 用 户 编写 的 reduce0 函 数 处 理 。 











口 Wirite 阶 段 ，reduce0 函 数 将 计算 结果 写 到 HDFS 上 。 


在 接 下 来 几 小 节 中 ， 我 们 将 详细 介绍 Shufle、Merge、Sort 和 和 Reduce 四 个 阶段 。 考 虑 到 Wirite 阶 段 比 较 简单 ， 我 们 不 再 介绍 。 








Shuffle/Copy Merge 





图 8-22 Map Task 计 算 流程 





8.4.2 Shuffle 和 Merge 阶 段 分 析 











在 Reduce Task 中 ，Shuffle 阶 段 和 Merge 阶 段 是 并 行进 行 的 。 当 远程 拷贝 数据 量 达 到 一 定 阐 值 后 ， 便 会 触发 相应 的 合并 线程 对 
数据 进行 合并 。 这 两 个 阶段 均 是 由 类 ReduceCopier 实 现 的 ， 该 类 大 约 包 含 2 200 行 代码 (整个 ReduceTask 类 才 2 900 行 左右 ) 。 如 图 
8-23 所 示 ， 总 体 上 看 ，Shuffle& Merge 阶 段 可 进一步 划分 为 三 个 子 阶段 。 


















































(1) 准备 运行 完成 的 Map Task 列 表 





GetMapEventsThread 线 程 周期 性 通过 RPC 从 TaskTracker 获 取 已 完成 Map Task 列 表 ， 并 保存 到 映射 表 mapLocations UR T 
TaskTracker Host 与 已 完成 任务 列表 的 映射 关系 ) 中 。 为 防止 出 现 网 络 热点 ，Reduce Task 通 过 对 所 有 TaskTracker Hostid: {7 “VEE Fe 
作 以 打 乱 数据 拷贝 顺序 ， 并 将 调整 后 的 Map Task 输 出 数据 位 置 保存 到 scheduledCopies 列 表 中 。 















































(2) 远程 拷贝 数据 




















Reduce Task 同 时 启动 多 个 MapOutputCopier 线 程 ， 这 些 线程 从 scheduledCopies 列 表 中 获取 Map Task 输 出 位 置 ， 并 通过 HTTP Get 
远程 拷贝 数据 。 对 于 获取 的 数据 分 片 ， 如 果 大 小 超过 一 定 阔 值 ， 则 存放 到 磁盘 上 ， 否 则 直接 放 到 内 存 中 。 


























(3) 合并 内 存 文件 和 磁盘 文件 








为 了 防止 内 存 或 者 磁盘 上 的 文件 数据 过 多 ，Reduce Task 启 动 了 LocalFSMerger 和 InMemFSMergeThread 两 个 线程 分 别 对 内 存 和 


磁盘 上 的 文件 进行 合并 。 
JobTracker 

















TaskTracker TaskTracker TaskTracker 
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scheduledCopies 
Local Disk 


图 8-23 Shuffe 阶 段 工 作 流 程 














接 下 来 ， 我 们 将 详细 刘 析 每 个 阶段 的 内 部 实现 细节 





C1) 准备 运行 完成 的 Map Task 


第 7 章 讲 到 ，TaskTracker 启 动 了 MapEventsFetcherThread 线 程 。 


列表 











该 线程 会 周期 性 











《周期 为 心跳 时 间 间 隔 ) 通过 RPC 从 JobTracker 




















上 获取 已 经 运行 完成 的 Map Task 列 表 ， 并 保存 到 TaskCompletionEvent 尖 型 列表 alMapEvents 中 。 








而 对 于 Reduce Task 而 言 ， 它 会 启动 GetMapEventsThread 线 程 。 
Task 列 表 ， 并 将 成 功 运行 完成 的 Map Task 放 到 列表 mapLocations 
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该 线程 周期 性 通 


过 RPC 从 TaskTracker 上 获取 已 运行 完成 的 Map 











P, Af on 





TaskTracker 


图 8-24 所 示 。 
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getTaskCompletionEvents ' 
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图 8-24 Reduce Task 获 取 完 成 Map Task 列 表 





为 了 避免 出 现 数据 访问 热点 〈 大 量 进程 集中 读 取 某 个 TaskTracker 上 的 数据 ) ，Reduce Task 不 会 直接 将 列表 mapLocations 中 的 
Map Task 输 出 数据 位 置 交 给 MapOutputCopier 线 程 ， 而 是 事先 进行 一 次 预 处 理 : 将 所 有 TaskTracker Host 进 行 混 洗 操作 《随机 打 乱 顺 


序 ) ， 然 后 保存 到 scheduledCopies 列 表 中 ， 而 MapOutputCopier 线 程 将 从 该 列表 
曾 拷贝 失败 的 Map Task 将 优 





的 是 ， 对 于 一 个 TaskTracker 而 言 ， 


(2) 远程 拷贝 数据 








Reduce Task 同 时 启动 mapred.reduce.paralleLcopies (默认 是 5) 个 数 


中 获取 Map Task 数 据 输出 描述 对 象 ， 











数据 临时 写 到 工作 目录 下 ， 和 否则 直接 保存 到 内 存 中 。 不 管 是 保存 到 内 存 中 ; 





















































Ph 获取 待 拷贝 的 Map Task 输 出 数据 位 置 。 需 要 注意 


先 获得 拷贝 机 会 。 





EF 贝 线程 MapOutputCopier。 该 线程 从 scheduledCopies 列 表 














并 利用 HITP Get 从 对 应 的 TaskTracker 远 程 拷贝 数据 ， 如 果 数 据 分 片 大 小 超过 一 定 阔 值 ， 则 将 





























对 象 描述 数据 的 元 信息 。 勾 
表 mapOutputFilesOnDisk 中 。 


Oo 














在 Reduce Task 中 ， 大 部 分 内 存 用 














定 ) 的 mapred.job.shuffle.input.buffer.percent( 默 认 是 0.70) 倍 ， 


于 缓存 从 Map Task 端 拷贝 的 数据 
并 日 























还 是 磁盘 上 ，MapOutputCopier 均 会 保存 一 个 MapOutput 
果 数 据 被 保存 到 内 存 中 ， 则 将 该 对 象 添 加 到 列表 mapOutputsFilesInMemory 中 ， 否 则 将 该 对 象 保存 到 列 





分 片 ， 这 些 内 存 占 到 JVM Max Heap Size (由 参数 -Xnx 指 
H2 ShuffleRamManager E. Reduce Task 规 定 ， 如 果 一 个 数据 分 片 











大 小 未 超过 该 内 存 的 0.25 倍 ， 则 可 存放 到 内 存 中 。 如 果 MapOutputCopier 线 程 要 拷贝 的 数据 分 片 可 存放 到 内 存 中 ， 则 它 先 要 向 


ShuffleRamManager 申 请 相应 的 内 存 ， 





待 同意 后 才 会 正式 拷贝 数 



































好 的 容错 机 制 是 非常 有 必要 的 。 当 出 





itt» 





否则 需要 等 





待 它 释 放 内 存 。 











由 于 远程 拷贝 数据 可 能 需要 跨 网 络 读 取 多 个 节点 上 的 数据 ， 期 间 很 容易 由 于 网 络 或 者 磁盘 等 原因 造成 读 取 失 败 ， 因 此 提供 良 
出 现 拷贝 错误 时 ，Reduce Task 提 供 了 以 下 几 个 容错 机 制 ; 
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口 如 果 找 贝 数据 出 错 次 数 超过 abortFailureLimit， 则 杀 死 该 Reduce Task 〈 等 待 调度 器 重新 调度 执行 ) ， 其 中 ，abortFailureLimiti 计 
算 方法 如 下 : 








abortFailureLimit=max{30, numMaps/10} 





口 如 果 找 贝 数 据 出 错 次 数 超过 maxFetchFailuresBeforeReporting (可 通过 参数 mapreduce.reduce.shuffle.maxfetchfailures 设 置 ， 默 认 是 








10) ， 则 进行 一 些 必要 的 检查 帽 ， 以 决定 是 否 杀 死 该 Reduce Task. 















































口 如 果 前 两 个 条 件 均 不 满足 ， 则 采用 对 数 回 归 模 型 推迟 一 段 时 间 后 重新 拷贝 对 应 MapTask 的 输出 数据 ， 
delayTinme 的 计算 方法 如 下 : 
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Ep HEIR ONY al 
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delayTime=10 000x1. 3noFailedFetches 





其 中 noFailedFetches 为 找 贝 错误 次 数 。 








(3) 合并 内 存 文件 和 磁盘 文件 



































前 面 提 到 ，Reduce Task 从 Map Task 端 找 贝 的 数据 ， 可 能 保存 到 内 存 或 者 磁盘 上 。 随 着 拷贝 数据 的 增多 ， 内 存 或 者 磁盘 上 的 文 
件数 目 也 必 将 增加 ， 为 了 减少 文件 数目 ， 在 数据 拷贝 过 程 中 ， 线 程 LocalFSMerger 和 InNMemFSMergeThread 将 分 别 对 内 存 和 磁盘 上 
的 文件 进行 合 3 






























































对 于 磁盘 上 文件 ， 当 文件 数目 超过 (2*ioSortFactor-1) 后 〈ioSortFactor 值 由 参数 io.sort, 包 ctor 指 定 ， 默 认 是 10) ， 线 程 


LocalFSMerger 会 从 列表 mapOutputFilesOnDisk 中 取出 最 小 的 ioSortFactor 个 文件 进行 合并 ， 并 将 合并 后 的 文件 再 次 写 到 磁盘 上 。 
























































对 于 内 存 中 的 文件 ， 当 满足 以 下 几 个 条 件 之 一 时 ，InMemFSMergeThread 线 程 会 将 内 存 中 所 有 数据 合并 后 写 到 磁盘 上 : 











口 所 有 数据 拷贝 完毕 后 ， 关 闭 ShuffleRamManager。 



































口 ShufleRamManager 中 已 使 用 内 存 超 过 可 用 内 存 的 mapred.job.shuffle.merge.percent (默认 是 66%) 倍 且 内 存 文件 数目 超过 2 个 。 














口内 存 中 的 文件 数目 超过 mapred.inmemmerge.threshold( 默 认 是 1 000) 。 




















口 阻塞 在 ShufleRamManager 上 的 请 求 数目 超过 拷贝 线程 数目 mapred.reduce.parallel.copies 的 75%。 




















[1 综合 考虑 Reduce Task 拷 贝 失败 的 数据 分 片 比例 、 找 贝 成 功 的 数据 分 片 比例 和 最 近来 拷贝 数据 持续 间隔 等 因素 。 


8.4.3 ”Sort 和 Reduce 阶 段 分 析 











当 所 有 数据 拷贝 完成 后 ， 数 据 可 能 存放 在 内 存 中 或 者 磁盘 上 ， 此 时 还 不 能 将 数据 直接 交 给 用 户 编写 的 reduce0 函 数 处 理 。 根 
据 MapReduce 语 义 ，Reduce Task 需 将 key 值 相同 的 数据 聚集 到 一 起 ， 并 按 组 将 数据 交 给 reduce0 函 数 处 理 。 为 此 ，Hadoop 采 用 了 基 
于 排序 的 数据 聚集 策略 。 前 面 提 到 ， 各 个 Map Task 己 经 事先 对 自己 的 输出 分 片 进行 了 局 部 排序 ， 因 此 ，Reduce Task 只 需 进 行 一 次 
归并 排序 即 可 保证 数据 整体 有 序 。 为 了 提高 效率 ，Hadoop 将 Sort 阶 段 和 Reduce 阶 段 并行 化 。 在 Sort 阶 段 ，Reduce Task 为 内 存 和 磁 
盘 中 的 文件 建立 了 小 顶 堆 ， 保 存 了 指向 该 小 顶 堆 根 节点 的 迭代 器 ， 且 该 迭代 器 保证 了 以 下 两 个 约束 条 件 : 














































































































口 磁 盘 上 文件 数目 小 于 io.sort.factor( 默 认 是 10)〉。 























口 当 Reduce 阶 段 开始 时 ， 内 存 中 数据 量 小 于 最 大 可 用 内 存 (JVM Max Heap Size) fJmapred.job.reduce.input.buffer.percent (ERV 


是 0) 。 











在 Reduce 阶 段 ，Reduce Task 不 断 地 移动 迭代 器 ， 以 将 key 相 同 的 数据 顺 次 交 给 reduce0 函 数 处 理 ， 期 间 移 动 迭 代 器 的 过 程 实际 
上 就 是 不 断 调整 小 顶 堆 的 过 程 ， 这 样 ，Sort 和 Reduce 可 并 行进 行 。 




















8.5 Map/Reduce Task 优 化 

















对 于 任何 一 个 作业 ， 可 从 应 用 程序 、 参 数 和 系统 三 个 角度 进行 性 能 优化 ， 其 中 ， 前 两 种 需 根据 应 用 程序 自身 特点 进行 ， 而 系 
统 优 化 需 从 Hadoop 平 台 设计 缺陷 出 发 进行 系统 级 改进 。 本 节 重 点 介绍 参数 调 优 和 系统 优化 两 种 方法 。 











8.5.1 参数 调 优 


由 于 参数 调 优 与 应 用 程序 的 特点 直接 相关 ， 































































































忆 此 本 小 节 仅 列 出 了 Map Task 和 Reduce Task 中 直接 影响 任务 性 能 的 一 些 可 调整 参 


数 〈 见 表 8-4 和 表 8-5) ， 具 体 调整 为 何 值 需 由 用 户 根据 作业 特点 自行 决定 。 
表 8-4 Map Task 可 调整 参数 
SEAN TT 
io.sort.mb Map Task 缓冲 区 所 占 内 存 大 小 100 MB 


io.sort.record.percent 


内 


io.sort.spill.percent 
到 
数 


mapred.compress.map.output 


mapred.map.output.compression.codec 
4 


2% ith kvoffsets 和 kvindices 共 占 io.sort.mb 的 0.05 
存 比 例 

缓冲 区 kvoffsets 或 者 kvoffsets 内 存 使 用 率 达 | 0.80 
该 比例 后 ， 会 触发 “ 溢 写 ”操作 ， 将 内 存 中 

据 写 成 一 个 文件 

是 否 压缩 Map Task 中 间 输 出 结果 foe 


如 果 支 持 压缩 Map Task 中 间 结 果 ， 则 采用 什 |  org.apache.hadoop. 
压缩 器 io.compress.zlib 





表 8-5 Reduce Task 可 调整 参数 


EHEN 


tasktracker.http.threads 


mapred.reduce.parallel.copies 


mapred.job.shuffle.input.buffer.percent 


mapred.job.shuffle.merge.percent 


mapred.inmem.merge.threshold 


io.sort.factor 


mapred.job.reduce.input.buffer.percent 














HTTP Server 上 的 线程 数 。 该 Server 运 行 在 每 个 
TaskTracker 上 ， 用 于 处 理 Map Task 输出 

Reduce Task 同时 启动 的 数据 拷贝 线程 数目 

ShuffleRamManager 管理 的 内 存 占 JVM Heap Max 
Size 的 比例 

当 内 存 使 用 率 超过 该 值 后 ， 会 触发 一 次 合并 ， 以 将 内 
存 中 的 数据 写 到 磁盘 上 

当 内 存 中 的 文件 超过 该 国 值 时 ， 会 触发 一 次 合并 ， 将 
内 存 中 的 数据 写 到 磁盘 上 

文件 合并 上 时， 一 次 合并 的 文件 数目 (合并 后 ， 将 合并 





后 的 文件 放 到 磁盘 上 继续 人 合并， 注意 ， 每 次 合并 时 ， 选 
择 最 小 的 前 io.sort.factor 进行 合并 ) 


Hadoop 假设 用 户 的 reduce() 函数 需要 所 有 的 JVM 内 
存 ， 因 此 执行 reduce) 函数 前 要 释放 所 有 内 存 。 如 果 设 
了 该 值 ， 可 将 部 分 文件 保存 在 内 存 中 不必 写 到 磁盘 上 ) 





默认 值 
40 


0.66 
1 000 


10 或 100 8 


考虑 到 Hadoop 中 用 户 可 配置 参数 非常 多 ， 为 了 简化 参数 配置 ， 一 些 研 究 机 构 尝试 自动 调 优 参数 ， 比 较 有 名 的 是 杜 克 大 学 的 
Starfish 项 目 ， 有 兴趣 的 读者 可 查看 网 站 : httpy/www.cs.duke.edu/starfsh/。 

















[1] Shuffle 阶 段 文 件 合 并 时 ， 该 值 默 认为 10;，Sort 阶 段 默 认 值 是 100。 





8.5.2 系统 优化 
































本 小 节 主要 讨论 Hadoop 的 性 能 优化 方向 ， 但 并 不 涉及 对 其 架构 进行 大 的 调整 或 者 改变 其 应 用 场景 。 





























TE Apache Hadoop 中 ，Map/Reduce Task 实 现存 在 诸多 不 足 之 处 ， 比 如 强制 使 用 基于 排序 的 聚集 策略 ，Shuffle 机 制 实现 过 于 低 效 等 。 为 此 ， 下 一 代 MapReduce 提 出 了 
很 多 优化 和 改进 方案 ， 主 要 体现 在 以 下 几 个 方面 中 。 









































1 .避免 排 序 站 




































































Hadoop 采 用 了 基于 排序 的 数据 聚集 策略 ， 而 该 策略 是 不 可 以 定制 的 。 也 就 是 说 ， 用 户 不 可 以 使 用 其 他 数据 聚集 算法 (如 Hash 聚 集 ) ， 也 不 可 以 跳 过 该 阶段 。 而 
在 实际 应 用 中 ， 很 多 应 用 可 能 不 需要 对 数据 进行 排序 ， 比 如 Hashjoin， 或 者 基于 排序 的 方法 非常 低 效 ， 比 如 SQL 中 的 "limit-k”。 为 此 ，HDH 版 本 D 提出 将 排序 变 成 可 选 
环节 ， 这 可 带 来 以 下 几 个 方面 的 改进 : 









































































































































口 在 Map Collect 阶 段 ， 不 再 需要 同时 比较 partition 和 key， 只 需 比 较 partition， 并 可 使 用 更 快 的 计数 排序 CO N) ) REREH CO (NIleN) ) 。 


















































口 在 Map Combine 阶 段 ， 不 再 需要 进行 归并 排序 ， 只 需 按照 字 节 合并 数据 块 即 可 。 























口 去 掉 排 序 后 ，Shuffle 和 Reduce 可 同时 进行 ， 即 Reduce 阶 段 可 提前 运行 ， 这 就 消除 了 Reduce Task 的 屏障 (所 有 数据 拷贝 完成 后 才能 执行 reduce0 函 数 )。 





2.Shuffle 阶 段 内 部 优化 

















(1) Map 端 Nettyft # Jetty 















































1.0.0 版 本 中 ，TaskTracker 采 用 了 Jetty 服 务 器 处 理 来 自 各 个 Reduce Task 的 数据 读 取 请 求 。 由 于 Jetty 采 用 了 非常 简单 的 网 络 模型 ， 因 此 性 能 比较 低 。 在 Apache Hadoop 
2.0.0 版 本 中 ，Hadoop 改 用 Netty， 它 是 另 一 种 开源 的 客户 /服务 器 端 编程 框架 。 由 于 它 内 部 采用 了 Java NIO 技 术 ， 相 比 Jetty 更 加 高 效 ， 且 Netty 社 区 更 加 活跃 ， 其 稳定 性 
比 Jetty 好 。 




















































































































(2) Reduce 端 一 一 批 找 贝 


1.0.0 版 本 中 ， 在 Shuffle 过 程 中 ，Reduce Task 会 为 每 个 数据 分 片 建立 一 个 专门 的 HITP 连 接 (One-connection-per-map) ， 即 使 多 个 分 片 同时 出 现在 一 个 TaskTracker 
上 ， 也 是 如 此 。 为 了 提高 数据 拷贝 效率 ，Apache Hadoop 2.0.0 尝 试 采 用 批 拷贝 技术 : 不 再 为 每 个 Map Task 建 立 一 个 HTTP 连 接 ， 而 是 为 同一 个 TaskTracker 上 的 多 个 Map 
Task 建 立 一 个 HITP 连 接 ， 进 而 能 够 一 次 读 取 多 个 数据 分 片 ， 具 体 如 图 8-25 所 示 。 







































































其 他 TaskTracker 
TaskTracker TaskTracker TaskTracker 


TaskTracker 
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其 他 TaskTracker 














图 8-25 ”One-connection-permap 与 批 拷贝 模型 对 比 


3. 将 Shuffle 阶 段 从 Reduce Task 中 拆 分 出 来 


























前 面 提 到 ， 对 于 一 个 作业 而 言 ， 当 一 定 比例 〈 默 认 是 5%) 的 Map Task 运 行 完 成 后 ，Reduce Task 才 开始 被 调度 ， 且 仅 当 所 有 Map Task 运 行 完 成 后 ，Reduce Task 才 
可 能 运行 完成 。 在 所 有 Map Task 运 行 完成 之 前 ， 已 经 启动 的 Reduce Task 将 始终 处 于 Shuffle 阶 段 ， 此 时 它们 不 断 从 已 经 完成 的 Map Task 上 远程 拷贝 中 间 处 理 结果 ， 由 于 
随 着 时 间 推 移 ， 不 断 会 有 新 的 Map Task 运 行 完 成 ， 因 此 Reduce Task 会 一 直 处 于 "等 待 一 找 贝 一 等 待 一 拷贝 .…… 的 状态 。 待 所 有 Map Task 运 行 完 成 后 ，Reduce Task 才 可 
能 将 结果 全 部 拷贝 过 来 ， 这 时 候 才能 够 进一步 调 户 编写 的 reduce0 函 数 处 理 数据 。 从 以 上 Reduce Task 内 部 运行 流程 分 析 可 知 ，Shuffle 阶 段 会 带 来 两 个 问题 ，slot 
Hoarding 和 资源 利用 率 低 下 。 

















































































































(1) Slot Hoarding 现 象 























Slot Hoarding 是 一 种 资源 围 积 现 象 ， 具 体 表现 是 ， 对 于 任意 一 个 MapReduce 作 业 而 言 ， 在 所 有 IMap Task 运 行 完成 之 前 ， 已 经 启动 的 Reduce Task 将 
释放 。Slot Hoarding 可 能 会 导致 一 些 作 业 产 生 饥 饿 现象 。 下 面 给 出 一 个 例子 进行 说 明 。 
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【实例 】 如 











8-26 所 示 ， 整 个 集群 
刻 ，job1 和 job2 的 Reduce Task 开 始 被 调 
Reduce Task 运 行 完 成 ;在 妇 时 刻 ，job3 的 Map Task 


g 








Ph 有 三 个 作业 ， 分 别 是 job1、job2 和 job3， 
度 ; EBZ 


















































其 中 ，job1 的 Map Task 数 目 非常 多 ， 而 其 他 两 个 作业 的 Map Task 相 对 较 少 。 在 0 时 
，job2 的 所 有 Map Task 运 行 完成 ， 不 久之 后 (3' 时 刻 ) ，job2 的 第 一 批 Reduce Task 运 行 完 成 ， 在 刨 时 刻 ，job2 所 有 
始 运 行 并 在 妇 时 刻 运行 完成 ， 但 由 于 此 时 所 有 Reduce slot 均 被 job1 占 因此 ， 除 非 job1 的 所 有 Map Task 运 行 完 





























成 ， 否 则 job3 的 Reduce Task 永 远 不 可 能 得 到 调度 。 
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图 8-26 多 个 作业 产生 Slot Hoarding 现 象 
(2) 资源 利用 率 低下 
从 资源 利用 率 角度 看 ， 为 了 保证 较 高 的 系统 资源 利用 率 ， 所 有 Task 都 应 充分 使 用 一 个 slot 所 隐 含 的 资源 ， 包 括 内 存 、CPU、1/O 等 资源 。 然 而 ， 对 单个 Reduce Task 
而 言 ， 在 整个 运行 过 程 中 ， 它 的 资源 利用 率 很 不 均衡 ， 总 体 上 看 ， 刚 开始 它 主要 使 用 VO 资源 ( Shuffle 阶段，， 之 后 主要 使 用 CPU 资 源 (Reduce 阶 段 ，。 如 图 8-27 所 
示 ， 妇 时 刻 之 前 ， 所 有 已 经 启动 的 Reduce Task 处 于 Shuffle 阶 段 ， 此 时 主要 使 用 网 络 WJO 和 磁盘 1/O 资 源 ， 而 在 如 时 刻 之 后 ， 所 有 Map Task 运 行 完成 ， 则 第 一 批 Reduce Task 
逐渐 开始 进入 Reduce 阶 段 ， 此 时 主要 消耗 CPU 资源 。 由 此 可 见 ，Reduce Task 运 行 过 程 中 使 用 的 资源 依次 以 LO、CPU 为 主 ， 并 没有 重 欠 使 用 这 两 种 资源 ， 这 使 得 系统 
整体 资源 利用 率 低 
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图 8-27 单个 作业 的 Reduce Task 资 源 利 用 率 分 析 




















率 低下 


ao 


经 过 以 上 分 析 可 知 ，JIO 密 集 型 的 数据 拷贝 《Shufle 阶 段 ) 和 CPU 密集 型 的 数据 计算 Reduce EO KEA TE — LE SBC Slot Hoarding 现象 和 系统 资源 利 
的 主要 原因 。 为 了 解决 该 问题 ， 一 种 可 行 的 解决 方案 是 将 Shuffle 阶 段 从 Reduce Task 中 分 离 出 来 ， 当 前 主要 有 以 下 两 种 具体 的 实现 方案 。 






































口 Copy-Compute Splitting: 这 是 Berkeley 的 一 篇 论文 内 提出 的 解决 方案 。 该 方案 从 逻辑 上 将 Reduce Task 拆 分 成 “Copy Task” 和 “Compute Task”， 其 中 ，Copy Task 用 于 
数据 拷贝 ， 而 Compute Task 用 于 数据 计算 (调用 用 户 编写 的 reduce0 函 数 处 理 数据 ) 。 当 一 个 Copy Task 和 运行 完成 后 ， 它 会 触发 一 个 Compute Task 进 行 数据 计算 ， 同 时 
外 一 个 Copy Task 将 被 启动 拷贝 另外 的 数据 ， 从 而 实现 1O 和 CPU 资源 重 登 使 用 。 
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口 将 Shuffle 阶 段 变 为 独立 的 服务 ， 将 Shuffle 阶 段 从 Reduce Task 处 理 逻 辑 中 出 来 变 成 为 一 个 独立 的 服务 ， 不 再 让 其 占用 Reduce slot， 这 样 也 可 达到 IJO 和 CPU 资源 重用 
































使 用 的 目的 。“ 百 度 ? 曾 采用 了 这 一 方案 口 。 

















4. 用 C++ 改写 Map/Reduce Task 
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利用 C++ 实现 Map/Reduce Task 可 借助 C++ 语言 独特 的 优势 提高 输出 性 能 。 当 前 比较 典型 的 实现 是 NativeTask 1 。NativeTask 是 一 个 C+ 实现 的 高 性 能 MapReduce 
行 单元 ， 它 专注 于 数据 处 理 本 身 。 在 MapReduce 的 环境 下 ， 它 仅 蔡 换 Task 模 块 功能 。 也 就 是 说 ，NativeTask 并 不 关心 资源 管理 、 作 业 调度 和 容错 等 ， 这 些 功 能 仍旧 由 
原 有 的 Hadoop 相 应 模块 完成 ， 而 实际 的 数据 处 理 则 改 由 这 个 高 性 能 处 理 引 擎 完成 。 

























































































与 Hadoop MapReduce 相 比 ，NativeTask 获 得 了 不 错 的 性 能 提升 ， 主 要 包括 更 好 的 排序 实现 、 关 键 路 径 避 免 序列 化 、 避 免 复杂 抽象 、 更 好 地 利用 压缩 等 。 












































[1 本 节 主 要 讨论 Hadoop 的 性 能 优化 方法 ， 这 些 方 法 不 会 对 其 进行 大 的 调整 ， 比 如 改变 其 架构 或 者 应 用 场景 (离线 改 为 在 线 )。 
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本 章 通过 将 任务 进行 阶段 细 分 ， 详 细 介绍 了 Map Task 和 Reduce Task 内 部 实现 原理 。 























本 章 将 Map Task 分 解 成 Read、Map、Collect、Spil 和 Conmbine 五 个 阶段 ， 并 详细 介绍 了 后 三 个 阶段 ，map0 函 数 处 理 完结 果 后 ，Map 
Task 会 将 处 理 结果 存放 到 一 个 内 存 缓冲 区 中 (Collect 阶 段 ，， 待 缓冲 区 使 用 率 达 到 一 定 阐 值 后 ， 再 将 数据 溢 写 到 磁盘 上 (Spil 阶 段 ，， 而 
当 所 有 数据 处 理 完 后 ，Map Task 会 将 磁盘 上 所 有 文件 合并 成 一 个 大 文件 〈Combine 阶 段 ) 。 这 几 个 阶段 形成 的 流水 线 如 图 8-28 所 示 。 
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图 8-28 Map Task 内 部 流水 线 

















本 章 将 Reduce Task 分 解 成 Shufte、Merge、Sort、Reduce 和 Waite 五 个 阶段 ， 且 重点 介绍 了 前 三 个 阶段 : Reduce Task 首 先进 入 Shuffle 阶 
段 ， 在 该 阶段 中 ， 它 会 启动 若干 个 线程 ， 从 各 个 完成 的 Map Task 上 拷贝 数据 ， 并 将 数据 放 到 磁盘 上 或 者 内 存 中 ， 待 文件 数目 超过 一 定 阔 
值 后 进行 一 次 合并 〈Merge 阶 段 } ， 当 所 有 数据 拷贝 完成 后 ， 再 对 所 有 数据 进行 一 次 排序 〈Sort 阶 段 ) ， 并 将 key 相 同 的 记录 分 组 依次 交 
给 reduce0 函 数 处 理 。 这 几 个 阶段 形成 的 流水 线 如 图 8-29 所 示 。 
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图 8-29 Reduce Task 内 部 流水 线 

















本 章 最 后 从 参数 调 优 和 系统 优化 两 个 角度 介绍 了 MapReduce 作 业 优 化 方法 。 





第 四 部 分 “MapReduce 高 级 篇 


本 部 分 内 容 





Hadoop 性 能 调 优 














Hadoop 多 用 户 作 业 调 度 器 








Hadoop 安 全 机 制 





下 一 代 MapReduce 框 架 
第 9 章 ”Hadoop 性 能 调 优 


在 前 几 章 中 ， 我 们 深入 介绍 了 Hadoop MapReduce 内 部 实现 原理 ， 包 括 JobTracker、TaskTracker、Task 等 组 件 的 实现 细节 。 基 
于 对 这 些 组 件 的 深入 理解 ， 用 户 可 以 很 容易 通过 调整 一 些 关 键 参数 使 作业 运行 效率 达到 最 优 。 本 章 将 分 别 从 Hadoop 管 理 员 和 用 
户 角 度 介绍 如 何 对 Hadoop 进 行 性 能 调 优 以 满足 各 自 的 需求 。 本 章 中 的 大 部 分 内 容 在 前 几 章 中 已 经 有 所 涉及 ， 如 果 你 对 Hadoop 优 
化 方法 已 经 非常 熟悉 ， 可 以 跳 过 本 章 。 











































































































9.1 概述 

















Hadoop 性 能 调 优 是 一 项 工程 浩大 的 工作 ， 它 不 仅 涉及 Hadoop 本 身 的 性 能 调 优 ， 还 涉及 更 底层 的 硬件 、 操 作 系 统 和 Java 虚 拟 机 
等 系统 的 调 优 ， 有 具体 如 图 9-1 所 示 。 对 这 几 个 系统 适当 地 进行 调 优 均 有 可 能 给 Hadoop 带 来 性 能 提升 。 





















































对 于 非 Hadoop 自 身 方面 的 性 能 调 优 ， 比 如 硬件 〈 如 CPU 类 型 、 内 存 大 小 的 选择 等 ) 、 操 作 系统 《比如 文件 系统 选择 、IO 
Scheduler 选 择 、 局 用 预 读 取 机 制 、 关 闭 swap 等 ) 、Java 虚 拟 机 (比如 调整 JVM 参 数 ) 等 ， 市 面 上 有 很 多 书籍 和 技术 文档 已 经 进行 
了 详细 介绍 ， 本 章 只 是 进行 简单 介绍 0 。 本 章 将 重点 讲解 如 何 通过 调整 Hadoop 自 带 的 一 些 参数 使 作业 运行 效率 达到 最 优 。 总 体 
来 说 ， 提 高 作业 运行 效率 需要 Hadoop 管 理 员 和 作业 拥有 者 共同 的 努力 ， 其 中 ， 管 理 员 负 责 为 用 户 提供 一 个 高 效 的 作业 运行 环 
境 ， 而 用 户 则 负责 根据 自己 作业 的 特点 让 它 尽 可 能 快 地 运行 完成 。 
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9-1 ”Hadoop 层 次 结构 图 














在 本 书 编写 时 ，Apache Hadoop 主 要 分 为 0.20.X (包括 1.X) 、0.21.X、0.22.X 和 0.23.X (包括 2.0 以 上 版 本 〉 四 个 系 
列 ，Cloudera Hadoop 主 要 分 为 CDH3 和 CDH 4 两 个 系列 ， 其 中 0.23.X (包括 2.0 以 上 版 本 ) 和 CDH 4 属于 下 一 代 MapReduce， 本 书 不 
予 讨论 。 这 里 重点 介绍 如 何 对 Apache 和 Cloudera 版 本 的 第 一 代 MapReduce 进 行 性 能 调 优 。 



































[1] 参考 AMD 的 技术 文档 “Hadoop Performance Tuning Guide” 和 Eric Sammer 的 书籍 《Hadoop Operations) 。 





9.2 ”从 管理 员 和 角度 进行 调 优 


















































管理 员 负 责 为 用 户 作业 提供 一 个 高 效 的 运行 环境 。 管 理 员 需 要 从 全 局 出 发 ， 通 过 调整 一 些 关 键 参数 值 提高 系统 的 吞吐 率 和 性 
能 。 总 体 上 看 ， 管 理 员 需 从 硬件 选择 、 操 作 系统 参数 调 优 、JVM 人 参数 调 优 和 Hadoop 参 数 调 优等 四 个 方面 入 手 ， 为 Hadoop 用 户 提 
供 一 个 高 效 的 作业 运行 环境 。 







































































9.2.1 硬件 选择 














Hadoop 自 身 架 构 的 基本 特点 决定 了 其 硬件 配置 的 选 型 。Hadoop 采 用 了 masterslave 架 构 ， 其 中 ，master (JobTracker 或 者 





















































NameNode) 维护 了 全 局 元 数据 信息 ， 重 要 性 远 远大 于 slave (TaskTracker 或 者 DataNode) 。 在 较 低 Hadoop 版 本 中 ，master 均 存在 单 


























点 故障 问题 ， 因 此 ，master 的 配置 应 远 远 好 于 各 个 slave (TaskTracker 或 者 DataNode) ， 具 体 可 参考 Eric Sammer 的 《Hadoop 
Operations》 一 书 。 


9.2.2 ”操作 系统 参数 调 优 





























于 Hadoop 自 身 的 一 些 特 点 ， 它 只 适合 
































] 于 将 Linux 作 为 操作 系统 的 生产 环境 。 











参数 进行 调 优 ， 可 在 一 定 程度 上 提高 作业 的 运行 效率 ， 比 较 有 用 的 调整 选项 如 下 。 




































































于 涉及 的 作业 和 任务 数目 非常 多 ， 对 于 某 个 节点 ， 








于 操 





(1) 增 大 同时 打开 的 文件 描述 符 和 网 络 连接 上 限 
在 Hadoop 集 群 中 » HJ 
方面 的 限制 ， 大 量 的 文件 读 写 操作 和 网 络 连接 可 能 导致 作业 运行 失败 ， 














Za 


FOE ANF 











的 文件 描述 符 数目 上 限 增 大 

















此 外 ，Hadoop RPC 采 
上 限 。 





] 了 epoll 作 为 高 并 发 库 ， 








(2) 关闭 swap 分 区 

















在 Linux 中 ， 如 果 








程 的 内 存 空间 





个 进 JANE, 





















































制 每 个 作业 处 理 的 数据 量 和 每 个 任务 运行 


中 的 vmswappiness 参 数 。 











过 程 中 














(3) 设置 合理 的 预 读 取 缓冲 区 大 小 














磁盘 VO 性 能 的 发 展 远 远 滞后 于 CPU 科 
数 和 应 用 程序 的 IO 等 待 时 间 ， 是 改进 


， 大 









































磁盘 读 IO 性 能 日 
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那么 ， 





四 























它 会 将 内 存 中 的 部 分 数 
据 动态 置换 到 内 存 中 ， 通 常 而 言 ， 这 种 行为 会 大 大 降低 进程 的 执行 效率 。 在 MapReduce 分 
j 到 的 各 种 缓冲 区 大 小 ， 避 免 使 用 swap 分 


而 成 为 现代 计算 机 系统 的 














大 




















EX MAGE, SH 





作 系 统 内 核 在 文件 描述 符 和 网 络 连接 数 
此 ， 管 理 员 在 启动 Hadoop 集 群 时 ， 应 使 月 

















用 的 Linux 内 核 版 本 在 2.6.28 以 上 ， 你 








Fi 











[时 写 到 磁盘 J 


个 合适 的 值 ， 同 时 调整 内 核 参 数 net.core.somaxconmn 至 一 个 足够 大 的 值 。 




















E 员 适当 对 Linux 内 核 


Age 




















调整 epol 的 文件 描述 


























Co 当 需 要 时 ， 





























区 。 








个 3 





ay 





6 重要 优 

















大 小 ， 以 提高 Hadoop 中 大 文件 





顺序 读 的 性 和 





(4) 文件 系统 选择 与 配置 











Hadoop 的 WO 性 能 很 大 程度 上 依赖 于 Linux 本 地 文 伯 

















FRITES H 


KF BCL 


要 








F 式 计算 环境 中 ， 

















将 磁盘 上 
j 户 完全 可 以 通过 控 
具体 方法 是 调整 /etc/sysctLconf 文 件 


























可 


有 ulimit 命 令 将 


的 数 





瑟 颈 。 预 读 可 以 有 效 地 减少 磁盘 的 寻 道 次 


。 管 理 员 可 使 用 Linux 命 令 blockdev 设 置 预 读 取 缓冲 区 的 
































区 大 小 ， 





kk 体 参 考 9.2.4 节 。 





能 。Linux 中 有 多 种 文件 系统 可 供 选择 ， 比 如 ex 和 ext4， 不 同 





E/N 











HIFR AERA ERAR H 司 内 音 














H 





不 公 


BAA EE 


发 的 更 高 效 


























在 Linux 文 件 系统 中 ， 当 未 
志 操 作 可 通过 将 其 添加 到 mount 属 


ay 


























性 中 避免。 








(5) IO 调度 器 选择 








主流 的 Linux 发 行 版 











站 























启用 noatime 属 性 时 ， 每 个 文人 



























































根据 自己 的 应 用 特点 启用 最 合适 的 IO 调度 器 ， 
除了 以 上 几 个 常见 的 Linux 内 核 调 优 方法 外 ， 还 有 一 些 

















的 文人 





带 了 很 多 可 供 选 择 的 WO 调度 器 。 在 数据 密集 型 应 用 
L 体 可 参考 AMD 的 白 


Re 





F 读 操作 会 触发 一 个 额外 的 文人 











系统 ， 也 鼓励 使 用 。 











h， 不 同 的 IO 调度 器 性 能 表现 差别 较 大 ， 管 理 


F 写 操作 以 记录 文件 最 近 访 问 时 间 。 该 











《Hadoop Performance Tuning Guide) 。 











他 的 方法 ， 管 理 员 可 根 








外 需要 进行 适当 调整 。 














9.2.3. JVM 参数 调 优 





单独 的 JVM 中 ， 因 此 ，JVM 的 一 些 重要 参数 也 会 影响 Hadoop 性 能 。 管 理 员 


皮 书 《Hadoop Performance Tuning Guide) 。 
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由 于 Hadoop 中 的 每 个 服务 和 任务 均 会 运行 在 
收 机 制 提 高 Hadoop 性 能 ， 有 具体 可 参考 AMD 的 白 
























































可 通过 调整 TYVM FLAGS 和 JVM 垃 圾 下 








9.2.4 ”Hadoop 参 数 调 优 


1. 合 理 规划 资源 





























CD 设置 合理 的 槽 位 数目 



































在 Hadoop 中 ， 计 算 资 源 是 用 槽 位 (slot〉 表示 的 。slot 分 为 两 种 : Map slot 和 Reduce slot。 每 种 slot 代 表 了 一 定量 的 资源 ， 且 同 种 
slot〈 比 如 Map slot) 是 同 质 的 ， 也 就 是 说 ， 同 种 slot 代 表 的 资源 量 是 相同 的 。 管 理 员 需 根据 实际 需要 为 TaskTracker 配 置 一 定数 目的 
Map slot 和 Reduce slot 数 目 ， 从 而 限制 每 个 TaskTracker 上 并 发 执行 的 Map Task 和 Reduce Task 数 目 。 













































































覃 位 数目 是 在 各 个 TaskTracker 上 的 mapred-site.xml 中 配置 的 ， 有 具体 如 表 9-1 所 示 。 














表 9-1 设置 槽 位 数目 


Hadoop 版 本 号 默认 值 
0.20.X (包括 1.X), CDH3 mapred.tasktracker.map.tasks.maximum 2 
mapred.tasktracker.reduce.tasks.maximum (两 个 参数 值 相同 ) 
0.21.X, 0.22.X mapreduce.tasktracker.map.tasks.maximum 2 
mapreduce.tasktracker.reduce.tasks.maximum (两 个 参数 值 相同 ) 








(2) 编写 健康 监测 脚本 


























Hadoop 人 允许 管理 员 为 每 个 TaskTracker 配 置 一 个 节点 健康 状况 监测 脚本 [1 。TaskTracker 中 包含 一 个 专门 的 线程 周期 性 执行 该 脚 


已 

















本 ， 并 将 脚本 执行 结果 通过 心跳 机 制 汇报 给 JobTracker。 一 旦 JobTracker 发 现 某 个 TaskTracker 的 当前 状况 为 “不 健康 ”( 比 如 内 存 或 者 
CPU 使 用 率 过 高 )， 则 会 将 其 加 入 黑 名 单 ， 从 此 不 再 为 它 分 配 新 的 任务 (当前 正在 执行 的 任务 仍 会 正常 执行 完毕 ) ， 直 到 该 脚本 执 
行 结果 显示 为 "健康 ”。 健 康 监测 脚本 的 编写 和 配置 的 具体 方法 ， 可 参考 7.3.1 节 。 
































































































































需要 注意 的 是 ， 该 机 制 只 有 Hadoop 0.20.2 以 上 版 本 中 有 。 











2. 调 整 心跳 配置 





(1) 调整 心跳 间隔 









































TaskTracker 与 JobTracker 之 间 的 心跳 间隔 大 小 应 该 适度 。 如 果 太 小 ，JobTracker 需 要 处 理 高 并 发 的 心跳 信息 ， 势 必 造 成 不 小 的 压 
A; 如 果 太 大 ， 则 空闲 的 资源 不 能 及 时 通知 JobTracker (进而 为 之 分 配 新 的 Task) ， 造 成 资源 空 尊 ， 进 而 降低 系统 吞吐 率 。 对 于 中 小 
规模 〈300 个 节点 以 下 ) 的 Hadoop 集 群 ， 缩 短 TaskTracker 与 JobTracker 之 间 的 心跳 间隔 可 明显 提高 系统 吞吐 率 。 



































在 Hadoop 1.0 以 及 更 低 版 本 中 ， 当 节点 集群 规模 小 于 300 个 节点 时 ， 心 跳 间隔 将 一 直 是 3 秒 〈 不 能 修改 ) 。 这 意味 着 ， 如 果 你 的 
集群 有 10 个 节点 ， 那 么 JobTracker 平 均 每 秒 只 需 处 理 3.3 (10/3=3.3) 个 心跳 请 求 ， 而 如 果 你 的 集群 有 100 个 节点 ， 那 么 JobTracker 平 均 


ANS 


每 秒 也 只 需 处 理 33 个 心跳 请 求 。 对 于 一 台 普 通 的 服务 器 ， 这 样 的 负载 过 低 ， 完 全 没有 充分 利用 服务 器 资源 。 综 上 所 述 ， 对 于 中 小 规 






















































































































































































模 的 Hadoop 集 群 ，3 秒 的 心跳 间隔 过 大 ， 管 理 员 可 根据 需要 适当 减 小 心跳 间隔 中， 具体 配置 如 表 9-2 所 示 。 

















表 9-2 设置 心跳 间隔 


Hadoop 版 本 号 默认 值 
0.20.X，0.21.X，0.22.X 不 可 配置 集群 规模 小 于 300 时 ， 心 跳 间 隔 为 
3 秒 ， 之 后 每 增加 100 个 节点 ， 则 心 
跳 间隔 增加 1 Rb 
LX CDH 3 mapreduce.jobtracker.heartbeat.interval.min 集群 规模 小 于 300 时 ， 心 跳 间 隔 为 

mapred.heartbeats.in.second 300 毫秒 (具体 解释 参考 6.3.2 小 节 ) 
mapreduce.jobtracker.heartbeats.scaling.factor 




















(2) 启用 带 外 心跳 




















通常 而 言 ， 心 跳 是 由 各 个 TaskTracker 以 固定 时 间 间 隔 为 周期 发 送 给 JobTracker 的 ， 心 跳 中 包含 节点 资源 使 用 情况 、 各 任务 运行 状 
息 。 心 跳 机 制 是 典型 的 pull-based 模 型 。TaskTracker 周 期 性 通过 心跳 向 JobTracker 汇 报信 息 ， 同 时 获取 新 分 配 的 任务 。 这 种 模型 

使 得 任务 分 配 过程 存 在 较 大 延 时 : 当 TaskTracker 出 现 空 闪 资源 时 ， 它 只 能 通过 下 一 次 心跳 (对 于 不 同 规模 的 集群 ， 心 跳 间 隔 不 同 ， 

比如 1 000 个 节点 的 集群 ， 心 跳 间 隔 为 10 秒 钟 ) 告诉 JobTracker， 而 不 能 立刻 通知 它 。 为 了 减少 任务 分 配 延迟 ，Hadoop 引 入 了 带 外 心 
























































Bk out-of-band heartbeat) DB] 。 带 外 心跳 不 同 于 常规 心跳 ， 它 是 任务 运行 结束 或 者 任务 运行 失败 时 触发 的 ， 能 够 在 出 现 空闲 资源 时 第 
一 时 间 通 知 JopTracker， 以 便 它 能 够 迅速 为 空闲 资源 分 配 新 的 任务 。 带 外 心跳 的 配置 方法 如 表 9-3 所 示 。 

















表 9-3 配置 带 外 心跳 











Hadoop 版 本 号 配置 参数 》 默认 值 
0.20.2 未 引 人 该 机 制 = 
0.20.X (ER 0.20.2),0.21.X, |mapreduce.tasktracker. 是 否 启用 带 外 心跳 false 
0.22.X, CDH 3 outofband. heartbeat 


3. 磁 盘 块 配置 




















Map Task 中 间 结 果 要 写 到 本 地 磁盘 上 ， 对 于 IJO 密 集 型 的 任务 来 说 ， 这 部 分 数据 会 对 本 地 磁盘 造成 很 大 压力 ， 管 理 员 可 通过 配置 
多 块 磁盘 缓解 写 压 力 。 当 存在 多 块 可 用 磁盘 时 ，Hadoop 将 采用 轮 询 的 方式 将 不 同 Map Task 的 中 间 结 果 写 到 这 些 磁盘 上 ， 从 而 平 挫 负 
载 ， 有 具体 配置 如 表 9-4 所 示 。 












































表 9-4 配置 多 个 磁盘 块 


Hadoop 版 本 号 配置 参数 RUE 
0.20.X 《包括 1.X), CDH 3 mapred.local.dir /tmp/hadoop-$ { user.name}/mapred/local 


0.21.X, 0.22.X mapreduce.cluster.local.dir /tmp/hadoop-$ {user.name }/mapred/local 





4. 设 置 合理 的 RPC Handler 和 HITP 线 程 数目 














(1) 配置 RPC Handler 数 目 





























JobTracker 需 要 并 发 处 理 来 自 各 个 TaskTracker 的 RPC 请 求 ， 管 理 员 可 根据 集群 规模 和 服务 器 并 发 处 理 能 够 调整 RPC Handler 数 目 ， 
以 使 JobTracker 服 务 能 力 最 佳 ， 配 置 方 法 如 表 9-5 所 示 。 
































表 9-5 配置 RPC Handler 数目 


Hadoop 版 本 号 默认 值 
10 


0.20.X (包括 1X)，CDH 3 
0.21.X, 0.22.X 





(2) 配置 HTTP 线 程 数目 





在 Shuffle 阶 段 ， 








些 HTTP 请 求 。 管 


Hadoop 版 本 号 





X, Reduce Task 通 过 HTTP 请 求 从 各 个 TaskTracker 上 读 取 Map Task 中 间 结 果 ， 而 每 个 TaskTracker 通 过 Jetty Server 处 到 


管理 员 可 适当 调整 Jetty Server 的 工作 线程 数 以 提高 Jetty Server 的 关 


mapred.job.tracker.handler.count 


10 


mapreduce.jobtracker.handler.count 


上 理 这 














并 发 处 理 能 力 ， 具 体 如 表 9-6 所 示 。 











表 9-6 配置 HTTP 线程 数目 
配置 参数 


默认 值 


404.20 汉 【〔 和 包括 1.X), CDH3 tasktrackerhttp.threads 40 
40 


0.21.X, 0.22.X 





5. 慎 用 黑 名 单机 制 





当 一 个 作业 运行 结束 时 ， 它 会 
作业 会 将 它 加 到 自己 的 黑 名 单 中 。 
单 ， 此 后 JobTracker 不 再 为 其 分 配 这 
























































当 Hadoop 和 集群 规模 较 小 时 ， 妇 
闭 该 功能 ， 具 体 配 置 方法 可 参考 6.5.2 小 节 。 

















6. 启 用 批量 任务 调度 








在 Hadoop 中 ， 调 度 器 是 最 核心 的 组 件 之 一 ， 它 负责 将 系统 中 空 





它 会 统计 在 各 个 TaskTracker 上 失败 的 任务 数目 。 如 果 
如 果 一 个 TaskTracker 被 一 定数 目的 作业 加 入 黑 
折 的 任务 ， 直 到 一 定时 间 段 内 没有 出 现 失败 的 任务 。 


[ 果 一 定数 量 的 节点 被 频繁 加 入 系统 黑 名 单 中 ， 则 会 大 大 降低 集 稻 


mapreduce.tasktracker.http.threads 








个 TaskTracker 失 败 的 任务 数目 超过 一 定 值 ， 则 
办 名 单 ， 则 JobTracker 会 将 该 TaskTracker 加 入 系统 黑 名 



































羊 知 吐 率 和 计算 能 力 ， 因 此 建议 关 























闲 的 资源 分 配给 各 个 任务 。 当 前 Hadoop 提 供 了 多 种 调度 




















默认 的 FIFO 调 度 器 、Fair Scheduler, Capacity Scheduler 等 ， 调 度 器 的 调度 效率 直接 决定 了 系统 的 吞吐 率 高 低 。 通 常 而 言 ， 为 了 将 空闲 


资源 尽 可 能 分 配给 任务 ，Hadoop 调 度 器 均 支 持 批量 任务 调度 四 














只 分 配 一 个 ， 有 具体 配 





x 
So 





， 即 一 次 将 所 有 空闲 任务 分 配 下 去 ， 而 不 是 


置 如 表 9-7 所 示 (FIFO 调 度 器 本 身 就 是 批量 调度 器 〉。 


表 9-7 配置 批量 任务 调度 


i) HE ai APR 


Capacity 
Scheduler 0.20.X (包括 1.X), 
CDH 3 
Fair 
Scheduler 


7. 选 择 合适 的 压缩 算法 





, | assignmultiple. 





mapred.capacity-scheduler. 每 次 心跳 最 多 分 
maximum-tasks-per-| 配 的 任务 数目 
heartbeat 


mapred.fairscheduler. 

assignmultiple 

mapred.fairscheduler. |, 

是 ， 则 一 次 最 多 分 
配 的 Map Task 和 
Reduce Task 数目 


maps 
mapred.fairscheduler. 
assignmultiple. 

reduces 

















Hadoop 通 常用 于 处 理 1/O 密 集 型 应 用 。 对 于 这 档 




















默认 值 
不 支持 批量 调度 ， 
-次 分 配 一 个 任务 
32 767 
不 支持 批量 调度 
-次 分 配 一 个 任务 


启用 批量 调度 功 


-| 能 ， 且 一 次 分 配 Map 
Task 和 Reduce Task 
的 最 高 数目 不 受 EIR 





的 应 用 ，Map Task 会 输出 大 量 中 间 数 据 ， 这 些 数据 的 读 写 对 用 户 是 透明 的 ， 如 果 




















能 够 支持 中 间 数 据 压 缩 存 储 ， 则 会 明显 提升 系统 的 IO 性 能 。 当 选择 压缩 算法 时 ， 需 要 考虑 压缩 比 和 压缩 效率 两 个 因素 。 有 的 压缩 算 
































法 需 平衡 压缩 比 和 压缩 效率 两 个 因素 。 

















当前 有 多 种 可 选 的 压缩 格式 ， 比 如 gzip、zip、bzip2、LZO [| 、Snappyl 等 ， 其 中 ，LZO 和 Snappy 在 压 















































法 有 很 好 的 压缩 比 ， 但 压缩 /解压 缩 效率 很 低 ， 反 之 ， 有 一 些 算 法 的 压缩 /解压 缩 效率 很 高 ， 但 压缩 比 很 低 。 因 此 ， 一 个 优秀 的 压缩 算 




















缩 比 和 压缩 效率 两 方面 的 


表现 都 比较 优秀 。 其 中 ，Snappy 是 Google 开 源 的 数据 压缩 库 ， 它 的 编码 /解码 器 已 经 内 置 到 Hadoop 1.0 以 后 的 版 本 中 中，LZO 则 不 
同 ， 它 是 基于 GPL 许 可 的 ， 不 能 通过 Apache 来 分 发 许可 ， 因 此 ， 它 的 Hadoop 编 码 /解码 器 必须 单独 下 载 9 。 























Fi 





以 Snappy 为 例 介绍 如 何 让 Hadoop 压 缩 Map 
































Task 中 间 输 出 数据 结果 〈 在 mapred-site.xml 中 配置 ) : 











<property> 


<name>mapred.compress.map.output</name> 


<value>true</value> 
</property> 
<property> 


<name>mapred.map.output.compression.codec</name> 
<value>org.apache.hadoop.io.compress.SnappyCodec</value> 


</property> 











H}, “mapred.compress.map.output #75 2 FE 
码 /解码 器 。 




















压缩 Map Task 中 间 输 出 结果 ，“imapred.map.output.conmmpression.codec” 家 示 采 用 的 编 


表 9-8 显 示 了 Hadoop 各 版 本 是 否 内 置 了 Snappy 压 缩 算法 。 





表 9-8 MÆ Snappy 压缩 算法 
Hadoop 版 本 号 是 否 内 置 Snappy 
0.20.X (AF 1.X), 0.21.X, 0.22.X 否 
1.X，CDH 3 是 
8. 启 用 预 读 取 机 制 

















前 











掉 提 到 ， 预 读 取 机 制 可 以 有 效 提 高 磁盘 的 IO 读 性 能 。 由 于 Hadoop 是 典型 的 顺序 读 系 统 ， 采 用 预 读 取 机 制 可 明显 提高 HDFS 读 























性 能 和 MapReduce 作 业 执 行 效率 。 管 理 员 可 为 MapReduce 的 数据 找 贝 和 IEike 文 件 读 取 启用 预 读 取 功 能 中 ， 有 具体 如 表 9-9 所 示 。 














表 9-9 配置 预 读 取 功 能 
Hadoop 版 本 号 配置 参数 i x 默认 值 





Apache 各 版 本 和 


时 oe A > 2k 一 
CDH 3 u3 以 下 版 本 暂 未 引入 该 机 制 


mapred.tasktracker.shuffle.fadvise 是 否 启 用 Shuffle 预 读 取 机 制 true 
CDH 3 u3 以 及 更 高 | Mapred.tasktracker.shuffle.readahead.bytes | Shuffle fi 读 取 缓冲 区 大 小 4 MB 


版 本 mapreduce.ifile.readahead 是 否 启 用 [File 预 读 取 机 制 true 
mapreduce.ifile.readahead.bytes IFile Hii R EK Kh 4 MB 





[1] httpsVissues. apache.org/jira/browse/ MAPREDUCE-211 
[2] httpsVissues. apache.orgjira/browse/MAPREDUCE- 1906 
[3] httpsVissues. apache.org/jira/browse/MAPREDUCE-2355 
[4] https://issues. apache.org/jira/browse/ HADOOP-3136 

[5] http://www. oberhumer.conyopensource/lzo/ 

[6] http://code. google.com/p/snappy/ 

[7] https://issues. apache.org/jira/browse/ HADOOP-7206 

[8] https://github. conytoddlipcon/hadoop-lzo 

[9] https://issues. apache.org/jira/browse/ HADOOP-7714 


9.3 ”从 用 户 角度 进行 调 优 

















Hadoop 为 





93l 


j 户 作业 提供 了 多 和 





























应 用 程序 编写 规范 















































FP 可 配置 的 参数 ， 以 允许 用 户 根 据 作业 特点 调整 这 些 参数 值 使 作业 运行 效率 达到 最 优 。 








尽管 本 章 主 要 从 参数 配置 方面 介绍 如 何 进行 Hadoop 调 优 ， 但 从 用 户 角度 来 看 ， 除 作业 配置 参数 外 ， 应 用 程序 本 身 的 编写 方 





式 对 性 能 影响 也 是 非常 大 的 。 在 编写 应 






































—t 














(1) 设置 Combiner 


对 于 一 大 批 MapReduce 应 月 
果 ， 从 而 减少 各 个 Reduce Task 的 远程 拷贝 数据 量 ， 








Task 中 间 输 出 结 


(2) 选择 合理 





在 MapReduce 模 型 
现 ， 包 括 IntWritable、FloatWritable。 为 应 用 程序 处 理 的 数据 类 型 选择 合适 的 Writable 类 型 可 大 大 提升 性 能 。 
转换 成 整 型 要 高 效 。 如 果 输 出 的 整 型 大 部 分 可 用 一 个 或 者 两 个 字 节 保存 ， 那 么 可 直接 采 
J VIntWritable 或 者 VLongWritable。 它 们 采用 了 变 长 整 型 编码 方式 ， 可 大 大 减少 输出 数 




















直接 有 






































的 Writable 类 型 


























H, Map Task 和 Reduce Task 的 输入 和 输出 数据 类 型 均 为 Writable。 
































程序 的 过 程 中 ， 谨 记 以 下 几 条 规则 对 提高 作业 性 能 是 十 分 有 帮助 的 。 





日 程序 ， 如 果 可 以 设置 一 个 Conbiner， 那 么 对 于 提高 作业 性 能 是 十 分 有 帮助 的 。Combiner 可 减少 Map 
最 终 表现 为 Map Task 和 Reduce Task 执 行 时 间 缩 短 。 


Hadoop 本 身 己 经 提供 了 很 多 Writable 实 
比如 处 理 整 型 数据 时 ， 























jjIntWritable 比 先 以 Text 类 型 读 入 



























































all 
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j 





9.3.2 ”作业 级 别 参数 调 优 


1. 规 划 合 理 的 任务 数目 














一 个 作业 的 任务 数目 对 作业 运行 时 间 有 重要 的 影响 。 如 果 一 个 作业 的 任务 数目 过 多 〈 这 意味 着 每 个 任务 处 理 数据 很 少 ， 执 行 时 间 
很 短 ，， 则 任务 启动 时 间 所 占 比例 将 会 大 大 增加 ; 反之， 如 果 一 个 作业 的 任务 数目 过 少 〈 这 意味 着 每 个 任务 处 理 数据 很 多 ， 执 行 时 间 
很 长 )》 ， 则 可 能 会 产生 过 多 的 滋 写 数据 影响 任务 执行 性 能 ， 且 任务 失败 后 重新 计算 代价 过 大 。 在 Hadoop 中 ， 每 个 Map Task 处 理 一 个 
Input Split. Input Spit 的 划分 方式 是 由 用 户 自 定义 的 InputFormat 决 定 的 ， 默 认 情 况 下 ， 由 以 下 三 个 配置 参数 决定 。 











pan 





























































































































口 mapred. min.split.size: Input Splt 的 最 小 值 〈 在 mapred-site.xml 中 配置 )。 











口 mapred. max.split.size: Input Sptt 的 最 大 值 〈 在 mapred-site.xml 中 配置 )。 














AdB. block.size: HDFS 中 一 个 block 大 小 (在 hdfs-site.xml 中 配置 )。 











Map Task 数 目的 具体 算法 可 参考 3.2.2 小 节 。 












































对 于 Reduce Task 而 言 ， 每 个 作业 的 Reduce Task 数 目 通常 由 用 户 决定 。 用 户 可 根据 估算 的 Map Task 输 出 数据 量 设置 Reduce Task 数 
以 防止 每 个 Reduce Task 处 理 的 数据 量 过 大 造成 大 量 写 磁 盘 操 作 。 
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2. 增 加 输入 文件 副本 数 











如 果 一 个 作业 并 行 执行 的 任务 数量 非常 多 ， 那 么 这 些 任 务 共同 的 输入 文件 可 能 成 为 瓶颈 。 为 防止 多 个 任务 并 行 读 取 一 个 文件 内 容 


造成 瓶颈 ， 用 户 可 根据 需要 增加 输入 文件 的 副本 数目 。 用 户 可 通过 在 客户 端 配置 文件 hdfs-site.xml 中 增加 以 下 配置 选项 修改 文件 副本 




































































数 ， 比 如 将 客户 端 上 传 的 所 有 数据 副本 数 设 置 为 51]: 

















<property> 
<name>dfs.replication</name> 
<value>5</value> 
</property> 








3. 启 用 推测 执行 机 制 














推测 执行 是 Hadoop 对 “ 拖 后 腿 ” 任 务 的 一 种 优化 机 制 。 当 一 个 作业 的 某 些 任务 运行 速度 明显 慢 于 同 作业 的 其 他 任务 时 ，Hadoop 会 在 
男 一 个 节点 上 为 “ 慢 任 务 " 启 动 一 个 备份 任务 ， 这 样 ， 两 个 任务 同时 处 理 一 份 数据 ， 而 Hadoop 最 终 会 将 优先 完成 的 那个 任务 的 结果 作为 
最 终结 果 ， 并 将 另外 一 个 任务 杀 掉 。 













































































用 户 可 通过 表 9-10 所 示 的 参数 设置 是 否 为 Map Task 和 Reduce Task 启 用 推测 执行 机 制 。 
































表 9-10 启用 推测 执行 机 制 
Hadoop 版 本 号 配置 参数 默认 值 


mapred.map.tasks.speculative.execution true 
mapred.reduce.tasks.speculative.execution (两 个 参数 值 相同 ) 





0.20.X (包括 1.X)，CDH 3 


mapreduce.map.speculative true 


0.21.X, 0.22.X s 
mapreduce.reduce.speculative (两 个 参数 值 相同 ) 












































不 同 Hadoop 版 本 ， 采 用 的 推测 执行 算法 不 同 ， 有 具体 可 参考 6.6 节 。 

















4. 设 置 失败 容忍 度 


Hadoop 允 许 设 置 作业 级 别 和 任务 级 别 的 失败 容忍 度 。 作 业 级 别 的 失败 容忍 是 指 Hadoop 允 许 每 个 作业 有 一 定 比 例 的 任务 运行 失败 ， 
这 部 分 任务 对 应 的 输入 数据 将 被 忽略 〈 这 些 数据 不 会 有 产 出 ) ; 任务 级 别 的 失败 容忍 是 指 Hadoop 允 许 任务 运行 失败 后 再 次 在 另外 节点 


















































上 尝试 运行 ， 如 果 一 个 任务 经 过 若干 次 尝试 运行 后 仍然 运行 失败 ， 那 么 Hadoop 才 会 最 终 认 为 该 任务 运行 失败 。 









































昌 户 应 根据 应 用 程序 的 特点 设置 合理 的 失败 容忍 度 ， 以 尽快 让 作业 运行 完成 和 避免 没 必要 的 资源 浪费 ， 具 体 设 置 如 表 9-11 所 示 。 

















表 9-11 设置 失败 容忍 度 








Hadoop 版 本 号 默认 值 
mapred.max.map.failures.percent 作业 最 多 允许 失败 的 Map| 0 (如 果 是 5， 表 示 

0.20.X (包括 mapred.max.reduce.failures.percent Task 和 Reduce Task 比例 为 5%) 

1.X), CDH 3 mapred.map.max.attempts 一 个 Map Task 或 者 Reduce 4 (两 个 参数 值 相 
mapred.reduce.max.attempts Task 最 多 尝试 次 数 同 ) 













mapreduce.map.failures.maxpercent 作业 最 多 允许 失败 的 Map| 0 (如 果 是 5， 表 示 


mapreduce.reduce.failures.maxpercent | Task 和 Reduce Task 比例 为 5%) 








mapreduce.map.maxattempts -个 Map Task 或 者 Reduce 4 (两 个 参数 值 相 
mapreduce.reduce.maxattempts Task 最 多 尝试 次 数 同 ) 


.适当 打开 JVM 重 用 功能 











为 了 实现 任务 隔离 ，Hadoop 将 每 个 任务 放 到 一 个 单独 的 JVM 中 执行 ， 而 对 于 执行 时 间 较 短 的 任务 ，JVM 启 动 和 关闭 将 占用 很 大 比 
例 的 时 间 ， 为 此 ， 用 户 可 启用 JVM 重 用 功能 ， 这 样 ， 一 个 JVM 可 连续 启动 多 个 同类 型 任务 ， 具 体 可 参考 7.6.1 节 。 设 置 JVM 重 用 的 方法 
如 表 9-12 所 示 。 













































































| 四 
tm 














pan 





























k 9-12 设置 JVM 重用 









默认 值 
1 
(1 表示 每 个 JVM 只 能 启动 一 个 Task ， 若 为 -1， 
则 表示 每 个 JVM 最 多 可 运行 的 Task 数目 不 受 限 
制 》 





Hadoop 版 本 号 


mapreduce.job.jvm.num.tasks 


6. 设 置 任务 超时 时 间 








在 一 些 特殊 情况 下 ， 一 个 任务 可 能 因为 某 种 原因 (比如 程序 Bug, Hadoop 本 身 的 Bug 等 ) 阻塞 了 ， 这 会 拖 慢 整个 作业 的 执行 进度 ， 
甚至 可 能 导致 作业 无 法 运行 结束 。 针 对 这 种 情况 ，Hadoop 增 加 了 任务 超时 机 制 。 如 果 一 个 任务 在 一 定时 间 间 隔 内 没有 汇报 进度 ， 则 
TaskTracker 会 主动 将 其 杀 死 ， 从 而 在 另外 一 个 节点 上 重新 启动 执行 。 
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j 户 可 根据 实际 需要 配置 任务 超时 时 间 ， 配 置 方法 如 表 9-13 所 示 。 














R 9-13 设置 任务 超时 时 间 
Hadoop 版 本 号 配置 参数 默认 值 


0.20.X (包括 1.X), CDH3 600 000 (单位 是 毫秒 ，10 分 钟 ) 
0.21.X, 0.22.X 600 000 (单位 是 毫秒 ，10 分 钟 ) 





7. 合 理 使 用 DistributedCache 


















































当 用 户 的 应 用 程序 需要 一 个 外 部 文件 (比如 字典 、 配 置 文件 等 时 ， 通 常 需要 使 用 DistributedCache 将 文件 分 发 到 各 个 节点 上 。 一 
股 情况 下 ， 得 到 外 部 文件 有 两 种 方法 : 一 种 是 外 部 文件 与 应 用 程序 jar 包 一 起 放 到 客户 端 ， 当 提交 作业 时 由 客户 端 上 传 到 HDFS 的 一 个 
目录 下 ， 然 后 通过 DistributedCache 分 发 到 各 个 节点 上 ;另外 一 种 方法 是 事先 将 外 部 文件 直接 放 到 HDFS 上 。 从 效率 上 讲 ， 第 二 种 方法 比 
第 一 种 更 高 效 。 第 二 种 方式 不 仅 节省 了 客户 端 上 传 文件 的 时 间 ， 还 隐 含 着 告诉 DistributedCache: “请 将 文件 下 载 到 各 节点 的 public 级 别 




































































































































































j 已 经 下 载 好 的 文件 ， 不 必 重 复 下 载 ， 即 “一 次 下 载 ， 终 生 受益 ?” 






































《而 不 是 private 级 别 ) 共享 目录 中 ” 这样， 后 续 所 有 的 作业 可 重 
体 参考 3$.4 节 。 
8. 合 理 控 制 Reduce Task 的 启动 时 机 
在 MapReduce 计 算 模 型 中 ， 由 于 Reduce Taskik $i] 
动 。 在 Hadoop 中 ， 合 理 控 制 Reduce Task 启 动 时 机 不 仅 可 以 加 快 作业 运行 速度 ， 
早 ， 则 可 能 由 于 Reduce Task 长 时 间 占 用 Reduce slot 资 源 造成 “slot Hoarding 现象 〈 
果 Reduce Task 启 动 过 晚 ， 则 会 导致 Reduce Task 获 取 资 源 延 迟 ， 增 加 了 作业 运行 





所 示 。 


表 9-14 


Hadoop 版 本 号 


0.20.X (包括 1.X)，CDH 3 


mapred.reduce.slowstart.completed.ma 


























FMap Task 的 执行 结果 ， 因 此 ， 从 运算 逻辑 上 讲 ，Reduce Task 应 晚 于 Map Task 启 
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且 可 提高 系统 资源 利 




















j 率 。 如 果 Reduce Task 启 动 过 




















体 可 参考 8.5.2 





设置 Reduce Task 启动 时 机 


ps (Map 


时 间 。Hadoop 配 置 Reduce Task 启 动 时 机 上 











入 )》， 从 而 降低 资源 利用 率 ， 反 之 ， 如 
的 参数 如 表 9-14 














默认 值 
0.05 
Task Sz 成 数 日 达 到 5% 时 ， 


开始 启动 Reduce Task ) 





0.21.X, 0.22.X 














mapreduce.job.reduce.slowstart.completed.maps 



























































































































































同上 













































































9. 跳 过 坏 记录 

Hadoop 是 用 于 处 理 海量 数据 的 ， 对 于 大 部 分 数据 密集 型 应 用 而 言 ， 丢 弃 一 条 或 者 几 条 数据 对 最 终结 果 的 影响 并 不 大 ， 正 因为 如 
此 ，Hadoop 为 用 户 提供 了 跳 过 坏 记 录 的 功能 。 当 一 条 或 者 几 条 坏 数据 记录 导致 任务 运行 失败 时 ，Hadoop 可 自动 识别 并 跳 过 这 些 坏 记 
录 ， 有 具体 配置 方法 可 参考 6.5.4 节 。 

10. 提 高 作业 优先 级 

所 有 Hadoop 作 业 调 度 器 进行 任务 调度 时 均 会 考虑 作业 优先 级 这 一 因素 。 一 个 作业 的 优先 级 越 高 ， 它 能 够 获取 的 资源 〈 指 slot 数 
E) 也 越 多 。 需 要 注意 的 是 ， 通 常 而 言 ， 在 生产 环境 中 ， 管 理 员 已 经 按照 作业 重要 程度 对 作业 进行 了 分 级 ， 不 同 重要 程度 的 作业 人 允许 
配置 的 优先 级 不 同 ， 用 户 不 可 以 擅自 进行 调整 。Hadoop 提 供 了 5 种 作业 优先 级 ， 分 别 是 VERY _ HIGH、HIGOH、NORMAL、LOW 和 


























] 户 可 在 允许 的 范 








VERY LOW. | 围 内 调整 作业 优先 级 以 获取 更 多 资源 ， 可 配置 





表 9-15 
Hadoop 版 本 号 
0.20.X (包括 1.X)，CDH 3 
0.21.X, 0.22.X% 


配置 参数 
































[1] 为 了 防止 该 参数 对 所 有 文件 生效 ， 可 创建 一 个 专门 的 配置 文件 仅 供 
件 有 效 ， 而 已 经 上 传 的 文件 副本 数 不 会 改变 。 











的 参数 如 表 9-15》 


设置 作业 优先 级 


mapred.job.priority 


mapreduce.job.priority 





TAN o 





默认 值 
NORMAL 
NORMAL 














了 需求 的 数据 使 用 。 另 外 ， 该 参数 只 对 参数 修改 之 后 上 传 的 文 


9.3.3 ”任务 级 别 参数 调 优 


1.Map Task 调 优 


























在 8.3 节 中 已 经 提 到 ，Map Task 的 输出 结果 将 被 暂时 存放 到 一 个 环形 缓冲 区 中 ， 这 个 缓冲 区 的 大 小 
位 是 MB， 默 认 是 100 MB) 。 该 缓冲 区 主要 




















参数 “io.sort.mb” 指 定 ( 单 
部 分 组 成 :索引 和 实际 数据 。 默 认 情况 下 ， 索 引 占 整个 buffer 的 比例 为 
下 的 空间 全 部 存放 数据 ， 当 且 仅 当 满 足以 下 任意 一 个 条 件 时 ， 才 会 触发 一 次 fush， 









































jio.sortrecord.percent〈 默 认为 0.05， 即 5%) , # 
生成 一 个 临时 文件 : 


























ral 





口 索 引 空间 使 用 率 达 到 比例 为 io.sortsp 记 percent 〈 默 认 是 0.8， 即 80%6) 。 


























ral 





口 数据 空间 使 用 率 达 到 比例 为 io.sortsp 记 percent (默认 是 0.8， 即 80%6) 。 


合理 


合理 地 调整 io.sort.record.percent 值 ， 可 减少 中 间 文 件数 目 ， 提 高 任务 执行 效率 。 举 例 说 明 ， 如 果 你 的 key/value 非 常 小 ， 则 可 以 
适当 调 大 io.sort.record.percent 值 ， 以 防止 索引 空间 优先 达到 使 用 上 限 触发 fosh。 考 虑 到 每 条 数据 记录 一 个 key/value) 需 占 
大 小 为 16 B， 因 此 ， 建 议 io.sort.record.percent=16/ (16+R) ， 其 中 R 为 平均 每 条 记录 的 长 度 。 















































索引 


















































综 上 所 述 ， 用 户 可 根据 自己 作业 的 特点 对 以 下 参数 进行 调 优 : 
Dio. sort.nb; 


Qio. sort.record.percent; 





Qio. sort.spill.percent. 


2.Reduce Task 调 优 



































在 8.3 节 中 已 经 提 到 ，Reduce Task 会 启动 多 个 拷贝 线程 从 每 个 Map Task 上 读 取 相应 的 中 间 结 果 ， 具 体 的 拷贝 线程 数目 由 参 
数 “mapred.reduce.parallel.copies”( 默 认为 5〉 指 定 。 对 于 每 个 待 拷贝 的 文件 ， 如 果 文 件 大 小 小 于 一 定 闷 值 A， 则 将 其 放 到 内 存 





























a 





否则 以 文件 的 形式 存放 到 磁盘 上 。 如 果 内 存 中 文件 满足 一 定 条 件 D， 则 会 将 这 些 数 据 写 入 磁盘 ， 而 当 磁 盘 上 文件 数目 达到 
io.sort.factor 〈 默 认 是 10) 时 ， 进 行 一 次 合并 。 浆 值 A 为 : 



























































heapsize* {mapred. job.shuffle.mput. buffer.percent} *0.25 

















其 中 ，heapsize 是 通过 参数 “mapred.child.java.opts” 指 定 的 ， 默 认 是 200 MB; mapred.job.shuffle.input.buffer.percent 默 认 大 小 为 0.7。 





条 件 D 为 以 下 两 个 条 件 中 任意 一 个 : 





























口内 存 使 用 率 《〈 总 的 可 
0.66) 。 








内 存 为 heapsize* {mapred.job.shuffle.input.buffer.percent} ) 达 到 mapred.job.shuffle.merge.percent( 默 认 是 





口内 存 中 文件 数目 超过 mapred.inmemmerge.threshold( 默 认 是 1 000) 。 


























综 上 所 述 ， 用 户 可 根据 自己 作业 的 特点 对 以 下 参数 进行 调 优 : 
Q mapred. reduce.parallel.copies; 


口 io. sort.factor; 





口 mapred. child.java.opts; 


Q mapred. job.shuffle.input.buffer.percent; 





口 mapred. inmem meree.threshold。 


9.4 小结 














Hadoop 性 能 调 优 是 一 项 























等 系统 的 调 优 。 本 章 从 硬 伯 


程 浩 


大 的 


工作 。 它 不 仅 涉 及 Hadoop 本 身 的 性 











能 调 优 ， 还 涉及 更 底层 的 硬件 、 操 作 系统 和 Java 虚 拟 机 








FF 、 操 作 系 统 、Java 虚 拟 机 和 Hadoop 参 数 调 优等 

















四 个 方面 介绍 了 Hadoop 性 能 调 优 的 方法 。 


第 10 章 


Hadoop 最 初 是 为 批 处 理 作 


Hadoop% H P VEM VIE gS 


























而 设计 的 ， 当 时 仅 采 用 了 


























Hadoop 集 群 



































程序 种 类 不 断 增加 ， 适 












































于 批 处 理 场景 的 FIFO 调 度 机 制 不 能 






































不 同 应 用 程 / 





从 目前 
拥有 全 套 独立 的 Hadoop 服 务 ， 比 如 JobTracker、 
Hadoop 调 度 器 ， 
























































j 户 作业 调度 器 的 设计 思路 














个 队列 多 用 








此 ， 设 计 适 用 于 多 用 户 的 作业 调度 器 势 在 必 行 。 
这 些 集群 各 自 

























































































j 场 景 和 设计 原理 。 








这 两 种 多 





10.1 多 用 户 调度 器 产生 


Hadoop 最 初 的 设计 目的 是 支持 大 数据 批 处 理 
调度 机 制 : FIFO， 即 先 来 先 服务 。 在 该 调度 机 制 下 ， 所 有 





业 。 


但 随 着 Hadoop 的 普及 ， 单 个 Hadoop 和 集群 的 用 户 


Of Service, QoS) ， 有 以 下 几 种 。 























j 户 作业 调度 器 的 应 


Ab = 
AAR 











个 物理 集群 上 虚拟 多 个 Hadoop 集 群 ， 
TaskTracker 等 ， 典 型 代表 是 HOD (Hadoop On Demand) 调度 器 ， 另 一 种 是 扩展 


主要 有 两 种 : 第 





户 ， 典 型 代表 是 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler。 本 章 将 重点 


作业 ， 如 











字 往 往 具有 不 同 的 服务 质 

































































口 批 处 理 作 





口交 互 式 作 期 望 能 及 时 返回 结果 ， 














要 求 有 一 定量 





口 生产 性 EY 








NT GEAR EBA 




















此 外 ， 这 些 
作业 一 般 为 JO 密 集 型 











IFIFO 调 度 器 的 不 足 ， 多 种 类 型 

















或 者 应 用 程序 


同 的 分 组 

















满足 各 利 








QoS R. HEZ 
各 自 拥有 全 套 独 立 也 
之 支持 多 个 队列 多 用 
Scheduler 和 Facebook 


























的 Fair Scheduler。 


往往 耗 时 较 长 ， 对 完成 时 间 一 般 没 有 严格 要 求 ， 如 数据 挖掘 、 机 器 学 习 等 方面 的 应 











全 资源 的 需求 量 也 是 不 同 的 ， 如 过 滤 、 
因此 ， 传 统 的 FIFO 调 度 策略 不 仅 不 能 请 











要 有 两 种 多 用 户 作业 调度 器 的 设计 思 
服务 ， 比 如 JobTracker、TaskTracker 等 ， 典 型 的 代表 是 HOD 调 度 器 ; 
羊 ， 不 同 的 队列 拥有 不 同 的 资源 量 ， 
接 下 来 将 分 别 介绍 这 两 种 多 用 














ERREK, PAHA i 








lim 





晶 随 着 Hadoop 的 普及 ， 单 个 
群 资源 ， 也 不 能 够 满足 























点 介绍 





、Web 索 引 等 作业 ， 为 此 ，Hadoop 仅 提供 了 一 个 非常 简单 的 
作业 被 统一 提交 到 一 个 队列 中 ，Hadoop 按 照 提 交 





交 顺 序 依次 运行 这 些 作 





TR (Quality 


























1SQL 查 询 (Hive) 等 。 





的 资源 保证 ， 如 统计 值 计算 、 垃 圾 数据 分 析 等 。 








统计 类 作业 一 般 为 CPU 密 外 
需求 ， 也 不 能 充分 利用 硬件 资源 。 























型 作业 ， 而 数据 挖掘 、 机 器 学 习 























调度 器 允许 管理 员 按照 应 














4 的 多 月 











需求 对 用 户 





























同时 通过 添加 各 种 约束 防止 单 





分 配 不 同 的 资源 量 ， 



































应 用 程序 独占 资源 ， 进 而 能 够 





























羊 上 虚拟 多 个 Hadoop 集 群 ， 这 些 集 群 
另 一 种 是 扩展 Hadoop 调 度 器 ， 使 
型 的 代表 是 Yahoo! 的 Capacity 



































可 以 运行 不 同 的 应 用 程序 ， 




















10.2 HOD 


HOD (Hadoop On Demand) HE4 U 
快速 搭建 若干 个 独立 的 虚拟 Hadoop 集 群 ， 
试 等 。HOD 调 度 器 可 使 





个 共 





HOD 调 度 器 首先 使 月 
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t 享 物理 
不 同 的 Hadoop 版 本 进行 测 








ERLE 






































的 各 个 守护 进程 ， 
接 下 来 将 分 别 介绍 Torque 资 源 管理 


10.2.1 


HOD 调 度 器 的 工作 过 程 


月 Torque 资 源 管理 

















FE 





个 在 


= se 
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群 上 管理 若干 个 Hadoop 集 群 的 工 















































器 器 为 一 个 虚拟 











管理 员 和 用 

















以 满足 不 同 的 用 途 ， 比 如 不 同 集群 运行 不 同类 型 
户 轻 松 地 快速 搭建 和 使 用 Hadoop。 


的 应 用 程序 














， 运 行 


有 具 。 用 户 可 通过 HOD 调 度 器 在 一 


Hadoop 集 群 分 配 节 点 ， 然 后 在 分 配 的 节点 上 启动 MapReduce 和 HDFS 中 











FA 

















Torque 资 源 管理 器 


ad 











业 的 运行 、 





维 





FEN 





























HOD 采 





一 个 Torque 


>a 





的 资源 管理 


[监控 各 个 作业 的 运行 状态 。 











器 是 





源 
原 




















集群 














TFA 




















动 为 Hadoop 守 护 进程 和 客户 端 生成 
器 和 HOPD 调 度 器 的 基本 














岗 中 依赖 于 一 个 资源 管理 器 


























节点 和 若干 个 计算 节点 组 成 。 头 节点 上 运行 一 个 名 为 pbs_server 的 守护 进程 ， 主 要 
每 个 计算 节点 上 运行 一 个 名 为 pbs_ mom 的 守护 进程 ， 




















口 








来 为 它 分 配 、 














适 的 配置 文件 〈 包 括 mapred-site.xml core-site.xmlfllhdfs-site xm) 。 
工作 原理 。 


回收 节点 和 管理 各 节点 上 的 作业 运行 的 情况 ， 如 监控 作 
的 运行 状态 等 。 而 HOD 只 需 在 资源 管理 器 所 分 配 的 节点 上 运行 Hadoop 守 护 进程 和 MapReduce 作 业 即 可 。 当 前 
的 Torque 资 源 管 理 器 。 











于 管理 






































用 于 执行 主 节 点 分 配 的 作业 。 



































任何 节点 作为 客户 端 ， 用 于 提交 和 管理 作业 。 
头 节点 内 部 还 运行 了 一 个 调度 器 守护 进程 。 该 守护 进程 会 与 pbs_server 进 行 通信 ， 以 诀 定 对 资源 使 用 和 作业 分 配 的 本 地 策 
略 。 默 认 情 况 下 ， 调 度 守 护 进 程 采用 了 FIFO 调 度 机 制 ， 它 将 所 有 作业 存放 到 一 个 队列 中 ， 并 按照 到 达 时 间 依 次 对 它们 进行 调 


























如 图 10-1 所 示 ， 


步 又] 


步骤 2 


步骤 3 


步骤 4 


步骤 


。 需 要 注意 的 是 ，Torque 中 的 调度 机 币 


























当 pbs_server 收 到 新 作业 




















调度 器 采用 一 





pbs_server 将 作业 发 送 给 





第 一 个 节点 启动 作业 ， 


JP] 通过 qsub 命 令 令 疝 物理 


定 的 策略 为 该 作业 分 配 节点 ， 






































后 ， 





步 通知 调 











会 进 





| 是 可 插 拔 的 ，Torque 还 提 作 


集群 中 提交 作业 ， 











:许多 其 他 可 选 的 作业 调度 器 。 








而 Torque 内 部 执行 流程 如 下 : 





度 器 。 
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作业 运行 完成 或 者 资源 





请 到 期 后 ，Torque 会 





并 将 节点 列表 与 节点 对 应 的 作业 执行 命令 





命令 返回 给 pbs_server。 


车 业 开始 运行 〈 该 作业 会 通知 其 他 节点 执行 相应 命令 ) 


回收 资源 。 





计算 节点 
此 外 ， 用 户 可 将 





图 10-1 Torque 内 部 工作 原理 
[1] http/hadoop. apache.org/docs/stable/hod scheduler.html 
[2] http//www. adaptivecomputing.conyproducts/open-source/torque/ 








10.2.2 HOD 作 业 调 度 





















































































































































理解 了 Torque 工 作 原理 后 ，HOD 调 度 器 工作 原理 便 一 目 了 然 : 首先 利用 Torque 向 物理 集群 申请 一 个 虚拟 机 群 ， 然 后 将 Hadoop 守 护 进 
成 一 个 Torque 作 业 ， 并 在 申请 的 节点 上 启动 ， 最 后 用 户 可 直接 向 启动 的 Hadoop 集 群 中 提交 作业 。 通 过 HOD 调 度 器 申请 集群 和 运行 
作业 的 主要 流程 如 下 : 



































步骤 1 用 户 向 HOD 调 度 器 申请 一 个 包含 一 定数 目 节点 的 集群 ， 并 要 求 该 集群 中 运行 一 个 Hadoop 实 例 。 


















































步骤 2 HOD 客 户 端 利用 资源 管理 器 接口 qsub 提 交 一 个 被 称 为 RingMaster 的 进程 作为 Torque 作 业 ， 同 时 申请 一 定数 目的 节点 。 这 个 作业 
被 提交 到 pbs_server 上 。 


















































步 又 3 在 各 个 计算 节点 上 ， 和 守护 进程 pbs_ mom 接 受 并 处 理 pbs_server 分 配 的 作业 。RingMaster 进 程 在 其 中 一 个 计算 节点 上 开始 运行 。 







































































步骤 4 RingMaster 通 过 Torque 的 另外 一 个 接口 pbsdsh 在 所 有 分 配 到 的 计算 节点 上 运行 第 二 个 HOD 组 件 HodRing， 即 运行 于 各 个 计算 节 
点 上 的 分 布 式 任务 。 











步骤 $ HodRing 初 始 化 之 后 会 与 RingMaster 通 信 以 获 取 Hadoop 指 令 ， 并 根据 指令 启动 Hadoop 服 务 进程 。 一 旦 服务 进程 开始 启动 ， 它 们 
会 向 RingMaster 登 记 ， 提 供 关于 守护 进程 的 信息 。 






























































注意 ”Hadoop 实 例 所 需 的 配置 文件 全 部 由 HOD 自 己 生 成 。HOD 客 户 端 保持 和 RingMaster 的 通信 ， 可 以 获取 MapReduce 和 HDFS 守 护 进 
程 所 在 的 位 置 






















































































ERO Hadoop 实 例 启动 之 后 ， 用 户 可 以 向 集群 中 提交 MapReduce 作 业 。 
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步 又 7 如 果 一 段 时 间 内 Hadoop 和 集群 上 没有 作业 运行 ，Torque 会 回收 该 虚拟 Hadoop 自 





















































管理 员 将 一 个 物理 集群 划分 成 若干 个 Hadoop 集 群 后 ， 用 户 可 将 不 同类 型 的 应 用 程序 提交 到 不 同 Hadoop 集 群 上 ， 这 样 可 避免 不 同 用 户 
或 者 不 同 应 用 程序 之 间 争 夺 资 源 ， 从 而 达到 多 用 户 共 享 集群 的 目的 。 
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从 集群 管理 和 资源 利用 率 两 方面 看 ， 这 种 基于 完全 隔离 的 集群 划分 方法 存在 诸多 问题 。 
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理 上 的 诸多 不 便 。 





口 从 集群 管理 角度 看 ， 多 个 Hadoop 集 群 会 给 运 维 人 员 造 成 























空间， 也 
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口 多 个 Hadoop 集 群 会 导致 集群 整体 利用 率 低下 ， 这 主要 是 负载 不 均衡 造成 的 ， 比 如 某 个 集群 非常 忙碌 时 另外 一 些 负 
就 是 说 ， 多 个 Hadoop 集 群 无 法 实现 资源 共享 。 



























































口 考 虑 到 虚拟 集群 回收 后 数据 可 能 丢失 ， 用 户 通常 将 虚拟 集群 中 的 数据 写 到 外 部 的 HDFS 上 。 如 图 10-2 所 示 ， 用 户 通常 仅 在 虚拟 集群 
上 安装 MapReduce， 至 于 HDFS， 则 使 用 一 个 外 部 全 局 共享 的 HDFS。 很 明显 ， 这 种 部 署 方 法 会 导致 形 失 部 分 数据 的 本 地 特性 。 为 了 解决 
该 问题 ， 一 种 更 好 的 方法 是 在 整个 集群 中 只 保留 一 个 Hadoop 实 例 ， 而 通过 Hadoop 调 度 器 将 整个 集群 中 的 资源 划分 给 若干 个 队列 ， 并 让 这 
些 队列 共享 所 有 节点 上 的 资源 ， 当 前 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler 正 是 采用 了 这 个 设计 思路 。 

























































































































































































MapReduce instancel MapReduce instance2 MapReduce instance3 


JobTracker 


JobTracker 





Shared HDFS 











图 10-2 基于 外 部 HDFS 的 多 个 虚拟 MapReduce 集 群 








10.3 ”Hadoop 队 列 管 


在 学 习 Capacity Scheduler 和 Fair Scheduler 之 前 ， 我 们 先 要 了 解 Hadoop 的 用 户 和 作业 管理 机 制 ， 


的 基础 。 


理 机 制 











Hadoop 以 队列 为 单位 管理 











作业 、 


























只 能 向 对 应 的 
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Hadoop 的 用 
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【实例 】 如 











模块 构建 在 操作 系统 


lf 中 所 有 队列 需 在 配置 文人 


ANS 





一 个 或 者 几 个 队列 中 提交 作业 。Hadoop 队 列 管理 机 
































] 户 管理 2 























群 中 有 四 个 队列 ， 





上 ， 增 加 了 “队列 ”这 一 
E 员 可 配置 每 个 队列 对 应 的 操作 系统 用 户 和 用 户 组 (需要 注意 的 是 ，Hadoop 人 允 询 
j 户 组 对 应 一 个 或 者 多 个 队列 ) ， 也 可 以 配置 每 个 队列 的 管理 员 。 


Fmapred-site.xml 中 设置 ， 














由 用 
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用 户 组 织 

















他 可 以 杀 死 该 队列 





这 意味 着 该 配置 信息 





yy 
JUs 








这 是 任何 Hadoop 可 捐 


j 户 和 资源 ， 整 个 Hadoop 集 群 被 划分 成 若干 个 队列 ， 每 个 队列 被 分 配 一 定 的 资源 ， 且 
户 权 限 管理 和 系统 资源 管理 两 部 分 组 成 ， 下 


通过 队列 建立 了 操作 系统 月 
F 一 个 操作 系统 月 
FP 任何 作业 ， 改 变 任何 作业 的 优先 级 





不 可 以 动态 加 载 。 





i 拔 调度 器 





H 


MIRI 


a 


4 


行 























HF All 
AP 








分 别 是 queueA、queueB、queueC 和 default， 那 么 可 以 在 mapred-site.xml 中 配置 如 下 : 








<property> 


<name>mapred.queue.names</name> 
<value>queueA, queueB, queueC, default</value> 
<description>Hadoop TATA BIZ PK</description> 


</property> 
<property> 
<name>mapred.acls 


.enabled</name> 


<value>true</value> 






































<description> #4 Ja AAIR HED AE </description> 
</property> 
队列 权限 相关 的 配置 选项 在 配置 文件 mapred-queue-acls.xml 中 设置 ， 这 些 信息 可 以 动态 加 载 。 

















【实例 】 如 果 规 定 
如 杀 死 任何 一 个 作业 或 者 











] 户 linux_userA 和 月 











改变 人 





有 户 组 linux_groupA 可 以 向 队列 queueA 中 1] 
FE 何 作业 的 优先 级 ) 队列 queueA， 那 么 可 以 在 mapred-queue-ack.xml 中 配置 如 下 : 
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作业 ， 





TEM 


H linux groupA_admin 可 以 管理 

















( 比 














<configuration> 
<property> 


<name>mapred. queue. queueA.acl-submit-job< /name> 
<value>linux_userA linux_groupA</value> 


</property> 
<property> 


<name>mapred. queue. queueA.acl-administer-jobs</name> 
<value>linux_ groupA_admin</value> 










































































































































































</property> 

<! -- 配 置 其 他 队列 .--> 

</configuration> 

2. 系 统 资源 管理 

Hadoop 资 源 管 理由 调度 器 完成 。 管 理 员 可 在 调度 器 中 设置 各 个 队列 的 资源 容量 、 各 个 用 户 可 用 资源 量 等 信息 ， 而 调度 器 则 
按照 相应 的 资源 约束 对 作业 进行 调度 。 考 虑 到 系统 中 的 队列 信息 是 在 mapred-site.xml 中 设置 的 ， 而 队列 资源 分 配 信息 在 各 个 调度 
器 的 配置 文件 中 设置 ， 因 此 ， 这 两 个 配置 文件 中 的 队列 信息 应 保持 一 致 是 十 分 重要 的 。 如 果 调 度 器 中 的 某 个 队列 在 mapred- 
site.xml 中 没有 设置 ， 则 意味 着 该 队列 中 的 资源 无 法 得 到 使 用 。 














常 而 言 ， 不 同 的 调 
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的 方式 是 不 同 的 。 接 下 来 将 介绍 Capacity Scheduler 和 Fair Scheduler 两 个 调度 器 的 工作 原 


10.4 Capacity Scheduler 实 现 








Capacity Scheduler!!! Yahoo! 开发 的 多 用 户 调度 器 。 它 以 队列 为 单位 划分 资源 ， 每 个 队列 可 设 定 一 定 比例 的 资源 最 低 保证 
和 使 用 上 限 ， 同 时 ， 每 个 用 户 也 可 设 定 一 定 的 资源 使 用 上 限 以 防止 资源 滥用 ， 而 当 一 个 队列 的 资源 有 剩余 时 ， 可 暂时 将 剩余 资源 
共享 给 其 他 队列 。 总 之 ，Capacity Scheduler 主 要 有 以 下 几 个 特点 。 






































































































































口 容 量 保证 : 管理 员 可 为 每 个 队列 设置 资源 最 低 保证 和 资源 使 用 上 限 ， 而 所 有 提交 到 该 队列 的 作业 共享 这 些 资源 。 
口 灵活 性 : 如 果 一 个 队列 中 的 资源 有 剩余 ， 可 以 暂时 共享 给 那些 需要 资源 的 队列 ， 而 一 旦 该 队列 有 新 的 作业 提交 ， 则 其 他 队 











列 释放 资源 后 会 归还 给 记 





队列 。 相 比 于 HOD 调 度 器 ， 这 种 资源 灵活 分 配 的 方式 可 明显 提高 资源 利用 率 。 


Ke 





















































口 多 重 租赁 : 支持 多 用 户 共享 集群 和 多 作业 同时 运行 。 为 防止 单个 作业 、 用 户 或 者 队列 独占 集群 中 的 资源 ， 管 理 员 可 为 之 增 
加 多 重 约束 《〈 比 如 单个 作业 同时 运行 的 任务 数 等 ) 。 






































口 支持 资源 密集 型 作业 : 当 一 个 作业 的 单个 任务 需要 的 资源 高 于 默认 设置 时 ， 可 同时 为 其 分 配 多 个 slot， 但 需要 注意 的 是 ， 
当前 仅 支 持 内 存 密集 型 作业 。 






























































口 支持 作业 优先 级 ， 默 认 情况 下 ， 在 每 个 队列 中 ， 空 闲 资源 优先 分 配给 最 早 提交 的 作业 ， 但 也 可 让 其 支持 作业 优先 级 ， 这 
样 ， 优 先 级 高 的 作业 将 优先 获取 资源 《两 个 作业 优先 级 相同 时 ， 再 按照 提交 时 间 优先 的 原则 分 配 资源 ) 。 需 要 注意 的 是 ， 当 前 
Capacity Scheduler 还 不 支持 资源 抢占 ， 也 就 是 说 ， 如 果 优先 级 高 的 作业 提交 时 间 晚 于 优先 级 低 的 作业 ， 则 高 优先 级 作业 需 等 待 低 
优先 级 作业 释放 资源 。 


















































10.4.1 Capacity Scheduler 功 能 介绍 
































Capacity Scheduler 是 一 个 多 用 户 调 度 器 。 它 设计 了 多 层级 别 的 资源 限制 条 件 以 更 好 地 让 多 用 户 共享 一 个 Hadoop 集 群 ， 比 如 队 
列 资源 限制 、 用 户 资 源 限制 、 用 户 作业 数目 限制 等 。 为 了 能 够 更 详尽 地 了 解 Capacity Scheduler 的 功能 ， 我 们 从 它 的 配置 文件 ; 
起 。Capacity Scheduler 有 自己 的 配置 文件 ， 即 存放 在 conf 目 录 下 的 capacity-scheduler.xml。 
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TE Capacity Scheduler 的 配置 文件 中 ， 队 列 queueX 的 参数 Y 的 配置 名 称 为 mapred.capacity-scheduler.queue.queueX.Y， 为 了 简单 起 
见 ， 我 们 记 为 Y， 则 每 个 队列 可 以 配置 的 参数 如 下 。 











Ocapacity: 队列 的 资源 容量 (百分比 )》。 当 系统 非常 繁忙 时 ， 应 保证 每 个 队列 的 容量 得 到 满足 ， 而 如 果 每 个 队列 作业 较 
少 ， 可 将 剩余 资源 共享 给 其 他 队列 。 注 意 ， 所 有 队列 的 容量 之 和 应 小 于 100。 









































口 maximum-capacity 队列 的 资源 使 用 上 限 (百分比 。 由 于 存在 资源 共享 ， 因 此 一 个 队列 使 用 的 资源 量 可 能 超过 其 容量 ， 
而 最 多 使 用 资源 量 可 通过 该 参数 限制 。 
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Osupports-priority: 是 否 支 持 作业 优先 级 。 默 认 情 况 下 ， 每 个 队列 内 部 ， 提 交 时 间 星 的 作业 优先 获得 资源 ， 而 如 果 支 持 优先 
级 ， 则 优先 级 高 的 作业 优先 获得 资源 ， 如 果 两 个 作业 优先 级 相同 ， 则 再 进一步 考虑 提交 时 间 。 
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口 minimunruser-limitrpercent， 每 个 用 户 最 低 资源 保障 〈 百 分 比 ) 。 任 何 时 刻 ， 一 个 队列 中 每 个 用 户 可 使 用 的 资源 量 均 有 一 定 
的 限制 。 当 一 个 队列 中 同时 运行 多 个 用 户 的 作业 时 ， 每 个 用 户 的 可 使 用 资源 量 在 一 个 最 小 值 和 最 大 值 之 间 浮 动 ， 其 中 ， 最 小 值 取 
决 于 正在 运行 的 作业 数目 ， 而 最 大 值 则 由 minimum-user-limit-percent 决 定 。 比 如 ， 假 设 minimunruser-limit-percent 为 25。 当 两 个 用 户 向 
该 队列 提交 作业 时 ， 每 个 用 户 可 使 用 资源 量 不 能 超过 50%; 如 果 三 个 用 户 提 交 作业 ， 则 每 个 用 户 可 使 用 资源 量 不 能 超过 33%; 如 
果 四 个 或 者 更 多 用 户 提交 作业 ， 则 每 个 用 户 可 使 用 资源 量 不 能 超过 25%。 




























































































































































































































































































Quser-limit-factor: 每 个 用 户 最 多 可 使 用 的 资源 量 〈 百 分 比 ) 。 比 如 ， 假 设 该 值 为 0， 则 任何 时 刻 ， 每 个 用 户 使 用 的 资源 量 不 
能 超过 该 队列 容量 的 30%。 
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O maximum initialized-active-tasks: 队列 中 同时 被 初始 化 的 任 
大 量 内 存 。 








务 数目 上 限 。 通 过 设置 该 参数 可 防止 因 过 多 的 任务 被 初始 化 而 占 

































































口 maximunrinitialized-active-tasks-per-user: 每 个 用 户 可 同时 被 初始 化 的 任务 数目 上 限 。 






































Uinit-accept-jobs-factor: 用 于 计算 队列 中 可 同时 被 初始 化 的 作业 数目 上 限 ， 即 为 (init-accept-jobs-factor) x (maximun system- 
jobs) xcapacity/100 














其 中 ，maximunrsystenrjobs 为 系统 中 最 多 可 被 初始 化 的 作业 数目 。 











一 个 配置 文件 实例 如 下 : 








<configuration> 

<property> 

<name>mapred.capacity-scheduler.maximum-system-jobs</name> 
<value>3000</value> 

<description> AAAS A BAA OM ELA </description> 

</property> 

<property> 

<name>mapred.capacity-scheduler.maximum-system-jobs</name> 
<value>3000</value> 

二 description>>Hadoop 集 群 中 最 多 同时 被 初始 化 的 作业 </description>> 

</property> 

<property> 

<name>mapred.capacity-scheduler.queue.myQueue. capacity</name> 
<value>30</value> 

description>default 队 列 的 可 用 资源 (百分比 ) </description> 

</property> 

<! = RE myQueueb\ Fl --> 

<property> 
<name>mapred.capacity-scheduler.queue.myQueue.maximum-capacity</name> 
<value>40</value> 

<dqescription>default 队 列 的 资源 使 用 上 限 〈 百 分 比 ) </description> 

</property> 

<property> 

<name>mapred.capacity-scheduler.queue.myQueue. supports-priority</name> 
<value>false</value> 

<description> £84 EWR </description> 

</property> 

<property> 

<name>mapred.capacity-scheduler. queue.myQueue.minimum-user-limit-—percent</name> 
<value>100</value> 

<description> AH RIRA ANHE) </description> 

</property> 

<property> 
<name>mapred.capacity-scheduler.queue.myQueue.user-limit-factor</name> 
<value>1</value> 

<description> fý 户 最 多 可 使 用 的 资源 占 队 列 总 资源 的 比例 </description> 

</property> 

<property> 
<name>mapred.capacity-scheduler.queue.myQueue.maximum-initialized-active-tasks</name> 
<value>200000</value> 
<description>defaulthAT AN Bae LMA 
</property> 
<property> 
<name>mapred.capacity-scheduler.queue.myQueue.maximum-initialized-active-tasks-—per- 
user</name> 
<value>100000</value> 
< description>default 队 列 中 每 个 用 户 可 同时 被 初始 化 的 任务 数目 < /description> 
</property> 
<property> 
<name>mapred.capacity-scheduler.queue.myQueue. init-accept-—jobs-factor</name> 
<value>10</value> 
二 description>default 队 列 中 可 同时 被 初始 化 的 作业 数目 ， 即 该 值 与 (maximum-system-jobs* 
queue-capacity) 的 乘积 </description> 

</property> 

<! -- 配 置 myoueue 队 列 .--> 

</configuration> 
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务 数目 < /description> 










































































从 上 面 这 些 参数 可 以 看 出 ，Capacity Scheduler 将 整个 系统 资源 分 成 若干 个 队列 ， 且 每 个 队列 有 较为 严格 的 资源 使 用 限制 ， 包 
括 每 个 队列 的 资源 容量 限制 、 每 个 用 户 的 资源 量 限制 等 。 通 过 这 些 限 制 ，Capacity Scheduler 将 整个 Hadoop 集 群 逮 辑 上 划分 成 若 3 
个 拥有 相对 独立 资源 的 子 集群 ， 而 由 于 这 些 子 集群 实际 上 共用 大 集群 中 的 资源 ， 因 此 可 以 共享 资源 ， 相 对 于 HOD 而 言 ， 提 高 了 
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资源 利用 率 且 降低 了 运 维 成 本 。 











[1] http//hadoop. apache.org/docs/stable/capacity scheduler.html 


10.4.2 Capacity Scheduler 实 现 


1.Capacity Scheduler 整 体 架 构 








第 5 半 中 已经 i 














了 作业 从 提交 到 调度 所 经 历 和 





的 几 个 步骤 。 对 于 Capacity Scheduler 而 言 ，JobTracker 


org.apache.hadoop.mapred.CapacityTaskScheduler (管理 员 需 在 参数 mapred.jobtracker.taskScheduler 中 指定 








加 载 自己 的 配置 文 























牛 capacity-scheduler xml， 并 向 JobTracker 注 册 监 听 器 以 随时 获取 作业 变动 信息 。 待 











如 图 








JobClient 





TaskTracker 





步骤 1 用 户 通过 Shel 命 令 提 交 作 业 后 ，JobClient 会 将 作业 提交 到 JobTracker 端 。 








步骤 2 ”JobTracker 通 过 监听 器 机 








作业 后 将 作业 添加 到 等 待 队列 中 ， 





步骤 3 某 一 时 刻 ， 一 个 TaskTracker 向 JobTracker 


10-3 所 示 ， 一 个 作业 从 提交 到 
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JobTracker 


o) 








图 











jobAdded() 


assignTasks() 


央 ， 将 新 提交 的 作业 同步 给 Capacity Scheduler" 

















台 调 度 所 经 历 的 步骤 大 致 如 下 : 


Function | 
Revocation ， 





JobInitializationPoller 













CapacityTaskScheduler 


MemoryMatcher 









10-3 ”作业 从 提交 到 开始 调度 的 整个 过 程 




















JobInitializationPoller 线 程 按 照 











步骤 4 JobTracker 检 测 到 TaskTracker 可 以 接收 新 的 任务 后 ， 调 


步骤 5 JobTracker 将 分 配 到 的 新 任务 返 匠 


接 下 来 将 习 


pan 





2. 作 业 初 始 化 


























点 介绍 作业 初始 化 和 作业 调度 相关 实现 。 











一 个 作业 经 初始 化 后 才能 够 进 

















作业 会 占用 JobTracker 内 存 ， 医 


























可 能 被 调度 器 调度 的 作业 和 限制 ) 

















于 作业 经 初始 化 后 才能 得 型 








ale, K 








来 限制 




















免 该 问 





Capacity Scheduler 中 作业 初始 化 | 














线程 JobInitializationPoller 完 成 。 








指定 ， 默 认 是 5) 工作 线程 JobInitializationThread 组 成 ， 每 个 了 








步骤 1 用 户 将 作业 提交 到 JobTracker 端 后 ，JobTracker 会 向 所 
JobQueuesManager 收 到 新 作业 添加 的 信 ， 











[ 作 线 程 


定 的 策略 对 作业 进行 初始 化 。 


























给 对 应 的 TaskTracker。 





内 存 使 用 量 。 


此 ， 如 果 任 务 初始 化 的 速度 慢 于 被 调度 速度 ， 则 可 能 会 产 49 
题 ，Capacity Scheduler 总 会 过 量 初始 化 一 些 任务 ， 从 而 让 一 部 分 任务 处 于 等 待 资源 的 状态 。 
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右 





该 线程 




















Capacity Scheduler 








启动 时 ， 会 自动 加 载 调度 器 类 
) ， 而 CapacityTaskScheduler 启 动 时 会 
周 度 器 





























启动 完 后 ， 





j 户 可 以 提交 作业 。 



















capacity- 
scheduler.xml 


JuoDlompPepSApedeD 





Pp 的 监听 器 JobQueuesManager; JobQueuesManager 收 到 新 


[ 报 心跳 ， 且 它 心跳 信息 中 要 求 JobTracker 为 其 分 配 新 的 任务 。 





jCapacityTaskScheduler.assignTasks() 函 数 为 其 分 配 任务 。 





步 得 到 调度 器 的 调度 而 获取 计算 资源 ， 因 此 ， 作 业 初 始 化 是 作业 开始 获取 资源 的 前 提 。 一 个 初始 化 的 
此 需 防止 大 量 不 能 立刻 得 到 调度 的 作业 被 初始 化 而 造成 内 存 浪费 。Capacity Scheduler 通 过 优先 初始 化 那些 最 
户 初 始 化 作业 数目 


空闲 资源 等 竺 任务 的 现象 。 为 了 避 


F 个 (可 通过 参数 mapred.capacity-scheduler.init-worker-threads 


负责 一 个 或 者 多 个 队列 的 作业 初始 化 工作 。 作 业 初 始 化 流程 如 下 : 











注册 的 监听 器 广播 该 作业 信息 ; 




















Capacity Scheduler 中 的 监听 器 
息 后 ， 检 查 是 否 能 够 满足 以 下 三 个 约束 ， 如 果 不 满足 ， 则 提示 作业 初始 化 失败 ， 和 否则 将 该 作业 添加 


到 对 














应 队列 的 等 待 作业 列表 


口 该 作业 的 任务 数 


口 队 列 中 等 待 初始 


口 该 用 户 等 待 初始 





O 


不 


化 和 已 经 初始 化 的 作 ， 


上 数 


超过 maximunrinitialized-active-tasks-per-user。 








不 超过 

















化 和 已 经 初始 化 的 作 ， 


上 数 

















不 超过 [ (maximunrsystenrjobs) xcapacity/100.0x Cminimun-user-limit- 








percent) 100.0]< (init-accept-jobs-factor) 。 


步骤 2 








oS 


mapred.capacity-scheduler.init-poll-intervalit7e, SRU Æ3 000228) 遍历 其 





口 队列 


























在 每 个 队列 
先 按照 作业 优先 级 排序 ， 再 按照 到 达 时 间 排 序 ) 排序 ， 和 否则 ， 按 照 作 业 到 达 时 间 排 序 。 每 个 工作 线程 每 隔 一 段 时 间 
对 应 的 作业 队列 ， 并 选 出 满足 以 下 几 个 条 件 的 作业 ; 


已 初始 化 作业 数目 


口 该 用 户 已 经 初始 化 作业 数 


口 该 用 户 已 经 初始 化 的 任务 数目 





一 





正 运行 的 作业 数 















































与 已 初始 化 但 未 运行 作业 数 































































































口 队列 中 已 初始 化 任务 数目 不 超过 maximunrinitialized-active-tasks。 


不 超过 maxinmm initialized-active-tasks-per-user。 











































































































































































































t (init-accept-jobs-factor) x (maximunrsystem-jos) xcapacity/100。 


F， 按 照 以 下 策略 对 未 初始 化 的 作业 进行 排序 ， 如 果 支 持 作 业 优 先 级 〈supports-priority 为 tue) ， 则 按照 FIFO 策 略 

















(可 通过 参 





> 和) 不 超过 [ (maxinmnrsystem-jobs)〉 xcapaity/100.0]。 


不 超过 [ (maximunrsystenrjobs) xcapacity/100.0x Cminimum-user-limit-percent) /100.0]。 








步骤 3 ”调用 JobTracker.iniJob0 函 数 对 筛选 出 来 的 作业 进行 初始 化 。 

3. 任 务 调度 

每 个 TaskTracker 周 期 性 向 JobTracker 发 送 心跳 汇报 任务 进度 和 资源 使 用 情况 ， 并 在 出 现 空闲 资源 时 请 求 分 配 新 任务 。 当 需要 为 某 个 
TaskTracker 分 配 任务 时 ，JobTracker 会 调用 调度 器 的 assignTasks 函 数 为 其 返回 一 个 待 运行 的 任务 列表 。 对 于 Capacity Scheduler 而 言 ， 该 
assignTasks 函 数 由 类 CapacityTaskScheduler 实 现 。 其 主要 工作 流程 如 图 10-4 所 示 ， 主 要 分 为 三 个 步 又 : 

WHR 更 新 队列 资源 使 用 量 。 在 选择 任务 之 前 ， 需 要 更 新 各 个 队列 的 资源 使 用 信息 ， 以 便 根据 最 新 的 信息 进行 调度 。 更 新 的 信息 
括 队 列 资源 容量 、 资 源 使 用 上 限 中、 正在 运行 的 任务 和 已 经 使 用 的 资源 量 等 。 





步骤 2 选择 Map Task。 正 如 第 6 章 所 述 ，Hadoop 调 度 器 通 




















更 新 各 个 队列 信息 








选择 Map Task 












选择 Reduce Task 





将 Task 列 表 返 回 给 TaskTracker 








图 





10-4 Capacity Scheduler 中 任务 分 配 过 程 























采用 三 级 调度 策略 ， 即 依次 选择 一 个 队列 、 该 队列 





党 


的 一 个 作业 和 该 作业 





中 的 一 个 任务 ，Capacity Scheduler 也 是 如 此 。 下 面 分 别 介绍 Capacity Scheduler 采 用 的 调度 策略 。 





先 将 资源 分 配给 资源 使 用 率 最 低 的 队列 ， 即 numSlotsOccupied/capacity 最 小 的 队列 ， 其 中 





口 选 择 队列 : Capacity Scheduler 总 是 优 # 
numSlotsOccupied 表 示 队 列 当前 已 经 使 用 的 slo 坝 目 ，capacity 为 队列 的 资源 容量 。 



































口 选择 作业 : 在 队列 内 部 ， 待 调度 作业 排序 策略 与 待 初始 化 作业 排序 策略 一 样 ， 即 如 果 支 持 作 业 优先 级 〈supports-priority 为 tue) ， 则 
按照 FIFO 策 略 排 序 ， 否 则 ， 按 照 作业 到 达 时 间 排 序 。 当 选择 任务 时 ， 调 度 器 会 依次 遍历 排 好 序 的 作业 ， 并 检查 当前 TaskTracker 剩 余 资源 是 
否 足 以 运行 当前 作业 的 一 个 任务 注意， 一 个 任务 可 能 同时 需要 多 个 slot) ， 如 果 满 足 ， 则 从 该 作业 中 选择 一 个 任务 添加 到 已 分 配 任 务 列 



































表 中 。 任 务 分 配 过 程 如 图 10-5 所 示 。 















pk 
是 否 正 为 某 
作业 预 留 






依次 遍历 每 个 队列 ， 针 对 每 
个 队列 ， 遍 历 其 内 部 的 作业 






该 TaskTracke 
当前 空闲 slot 是 否 足 
以 运行 该 作业 
一 个 任务 2 




















该 TaskTracke 
当前 空闲 slot 是 





一 人) 









让 TaskTracker 继 续 为 该 作 将 该 作 ， 个 任 
业 项 预 留 资源 让 TaskTracker 将 剩余 slot 预 留 
给 该 作业 


已 分 配 任务 

















数 是 否 达到 为 当前 作业 预 家 
maxTasksPer 任务 的 TaskTracker 数 


站 相思 全 





Heartbeat? 


图 10-5 Capacity Scheduler 任 务 分 配 流程 图 








Capacity Scheduler 调 度 过 程 用 到 了 以 下 几 个 机 制 。 


机 制 1: 大 内 存 任务 调度 。 





Capacity Schedulerté 4 


虑 到 一 
为 其 
空闲 的 s 














默认 情况 下 ， 大 内 存 任务 调度 机 制 是 关闭 的 ， 


mapred.cluster.max.map.memory.mb、 mapred.cluster.max.reduce.memory.nmb 站 








lot, 直 = 




















式 计 算 每 个 Map Task 需 


1 累计 预 留 的 slot 数 目 























t 了 对 大 内 存 任 务 的 调 
个 slot 代 表 的 内 存 是 一 定 的 ， 因 此 这 


分 配 一 个 或 者 多 个 slot。 如 果 当 前 TaskTracker 空 亲 


度 机 制 。 

















没 








默认 情况 下 ，Hadoop 假 设 所 有 但 
考虑 那些 内 存 密集 型 














Slot 数目 





小 于 作 














的 单个 任 























满足 当前 作 








此 的 单个 任务 需求 ， 


只 有 当 管 理 














员 配 置 




















要 的 slot 数 (Reduce Task 计 算 方 法 类 似 ) : 


[ ${mapred. job.map.memory.mb}/$ {mapred.cluster.map.memory.mb} | 

















































































































































































































FE 务 是 同 质 的 ， 任 何 一 个 各 
4 的 任务 。 为 解决 该 问题 ，Capacity Scheduler 可 根据 任务 的 内 存 需求 和 
务 的 需求 量 ， 调 度 器 会 
此 时 ， 才 会 真正 地 将 该 任务 分 配给 TaskTracker 执 行 。 











让 TaskTracker 为 该 作业 预 留 器 当 

















F 务 只 能 使 用 一 个 slot， 考 














a 





= 








T mapred.cluster.map.memory.mb, mapred.cluster.reduce.memory.mb, 
个 参数 后 ， 才 会 文 持 大 内 存 任务 调度 ， 此 时 ， 调 度 器 会 按照 以 下 公 



















































































MLZ: 通过 任务 延迟 调度 以 提高 数据 本 地 性 。 

第 6 章 提 到 ， 当 任务 的 输入 数据 与 分 配 到 的 slot 位 于 同一 个 节点 或 者 机 架 时 ， 称 该 任务 具有 数据 本 地 性 。 数 据 本 地 性 包含 三 个 级 别 ， 分 
别 是 node-local (输入 数据 和 空闲 slot 位 于 同一 个 节点 ) rack-local (输入 数据 和 空闲 slot 位 于 同一 个 机 架 ) 和 o 企 switch 〈 输 入 数据 和 空闲 slot 
位 于 不 同 机 架 ) 。 由 于 为 空闲 slot 选 择 具有 本 地 性 的 任务 可 避免 通过 网 络 远 程 读 取 数 据 进而 提高 数据 读 取 效率 ， 所 以 Hadoop 会 优先 选择 
node-local 的 任务 ， 然 后 是 rack-local， 最 后 是 offswitch。 

为 了 提高 任务 的 数据 本 地 性 ，Capacity Scheduler 采 用 了 作业 延迟 调度 的 策略 : 当选 中 一 个 作业 后 ， 如 果 在 该 作业 中 未 找到 满足 数据 本 
地 性 的 任务 ， 则 调度 器 会 让 该 作业 跳 过 一 定数 目的 调度 机 会 ， 直 到 找到 一 个 满足 本 地 性 〈node-loca] 或 rack-local) 的 任务 或 者 达到 跳 过 次 数 
上 限 CrequiredSlotsxlocalityWaitFactor) ， 其 中 ，localityWaitFactor 可 通过 参数 mapreduce.job.locality.wait.factor 配 置 ， 默 认 情 况 下 ， 计 算 方法 如 

localityWaitFactor=min{jobNodes/clusterNodes, 1} 
其 中 ，jobNodes 表 示 该 作业 输入 数据 所 在 的 节点 总 数 ; clusterNodes 表 示 整 个 集群 中 节点 总 数 。 

requiredSlots 计 算 方法 如 下 : 

requiredSlots=min{ (numMapTasks-finishedMapTask) , numTaskTrackers} i 
其 中 ，numMapTasks、finishedMapTasks 分 别 表示 该 作业 总 的 Map Task 数 目 和 已 经 运行 完成 的 Map Task 数 目 ;，numiTaskTrackers 表 示 整 个 











集群 中 





MTaskTracker 数 








HLH 


为 了 加 快 
heartbeat (默认 是 ShortMAX VALUE) 指定 一 次 性 
发 送 心跳 的 TaskTracker， 也 就 是 说 ， 当 系统 slot 数 
务 也 可 能 会 





























13: 批量 任务 分 配 。 


GER, 


步骤 3: 选择 Reduce Task. 

















相 比 于 Map Task, Reduce Task 选 择机 制 就 简单 多 了 。 它 仅 采 用 了 大 内 存 任 务 调 度 策 略 ， 至 于 其 他 策略 ， 如 但 
没有 数据 本 地 性 ) 和 批量 任务 分 配 等 ， 不 再 采用 。 调 度 器 只 要 找到 一 个 合适 的 Reduce Task 便 可 以 返回 。 
[1] 队列 的 资源 容量 和 资源 使 用 上 限 是 在 配置 文件 中 配置 的 百分比 。 在 一 个 运行 的 Hadoop 集 群 中 ， 节 点 的 数目 
该 百分比 求 出 来 的 资源 量 也 是 变化 的 。 
D] 预 留 : 暂时 占 下 slot， 尽 管 没有 实际 使 用 ， 但 可 防止 被 其 他 任务 占用 。 























由 于 一 个 节点 上 可 能 























E 务 分 配 速 度 ，Capacity Scheduler 支 持 批量 人 各 
为 一 个 TaskTracker 分 配 的 最 多 任务 数 。 
目 时 ， 会 使 得 和 有 

















KFE 














E 务 分 配 ， 


管理 




















中 分 配 到 几 个 节点 上 ， 这 不 利于 负载 均衡 。 























员 可 通过 

















E 务 集中 




















































































































































































































于 多 个 TaskTracker， 因 此 numiTaskTrackers 与 clusterNodes 可 能 不 相等 )。 


过 参数 mapred.capacity-scheduler.maximunrtasks-per- 
需要 注意 的 是 ， 该 机 制 倾向 于 将 任务 分 配给 优先 


运行 在 少数 几 个 节点 上 ， 





且 同 一 个 作业 的 任 





E 务 延迟 调度 (Reduce Task 








是 不 断 变化 的 ， 因 此 ， 通 过 














10.4.3 ”多 层 队 列 调度 





每 个 队列 可 能 代表 一 个 部 





引进 一 步 划 分 。 但 在 实际 应 用 中 ， 
同 队列 中 ， 最 终 形 成 一 个 树 形 组 织 结构 。 





级 结构 组 织 在 一 起 ， 且 每 个 队列 不 能 了 








在 Hadoop 1.0 中 ， 队 列 以 习 
门 ， 该 部 门 可 能 又 进一步 划分 成 若干 个 子 部 门 或 者 将 自己 的 资源 按照 应 用 类 型 划分 到 不 





一 个 典型 的 例子 如 图 10-6 所 示 。 




















E 现 有 实现 基础 上 添加 了 对 多 层 队 列 的 支持 ， 主 要 特性 





H, Capacity Scheduler# 





为 了 支持 这 种 多 层 队 列 组 织 方式 ， 在 Hadoop 2.04 





如 下 : 








FP 间 队列 包含 若干 子 队列 ， 而 叶子 队列 没有 再 分 解 的 队列 。 

















口 整个 组 织 结构 由 中 间 队 列 和 叶子 队列 组 成 ， 其 中 ,| 


tt 
3 








口 任何 队列 可 划分 成 若干 子 队列 ， 但 子 队列 容量 之 和 不 能 超过 父 队列 总 容 








口 用 户 作 业 只 能 将 作业 提交 到 菜 个 叶子 队列 中 。 























EYS 
共享 给 


图 10-6 为 例 ， 当 队列 C11 中 有 剩余 资源 时 ， 首 先 共 











口 当 某 个 队列 出 现 空闲 资源 时 ， 优 先 共 享 给 同 父亲 的 其 他 子 队列 。 以 














Cl12， 其 次 是 C2， 最 后 才 是 Al1，A2 和 Bl。 

















的 调度 机 制 与 现 有 的 调度 机 制 一 致 。 














口 进行 任务 调度 时 ， 仅 考虑 叶子 队列 ， 且 采用 











图 10-6 Capacity Scheduler 多 层 队 列 结构 图 
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10.5 Fair Scheduler 实 现 

















Fair Scheduler ||! 是 Facebook 开 发 的 多 用 户 调度 器 。 与 Capacity Scheduler 类 似 ， 它 以 资源 池 “ 与 队列 一 个 概念 ) 为 单位 划分 资 
源 ， 每 个 资源 池 可 设 定 一 定 比例 的 资源 最 低 保证 和 使 用 上 限 ， 同 时 ， 每 个 用 户 也 可 设 定 一 定 的 资源 使 用 上 限 以 防止 资源 滥用 ; 当 
一 个 资源 池 的 资源 有 剩余 时 ， 可 和 暂时 将 剩余 资源 共享 给 其 他 资源 池 。 当 然 ，Fair Scheduler 也 存在 很 多 与 Capacity Scheduler 不 同 之 
处 ， 主 要 体现 在 以 下 几 个 方面 。 







































































口 资 源 公 平 共享 : 在 每 个 资源 池 中 ，Fair Scheduler 可 选择 按照 FIFO 或 者 Fair 策 略为 作业 分 配 资源 ， 其 中 Fair 策 略 是 一 种 基于 最 
大 最 小 公平 算法 丫 实 现 的 资源 多 路 复 用 方式 ， 默 认 情 况 下 ， 每 个 队列 内 部 采用 该 方式 分 配 资源 。 这 意味 着 ， 如 果 一 个 队列 中 有 
个 作业 同时 运行 ， 则 每 个 作业 可 得 到 1/2 的 资源 ， 如 果 三 个 作业 同时 运行 ， 则 每 个 作业 可 得 到 1/3 的 资源 。 








































































































口 支持 资源 抢占 : 当 某 个 资源 池 中 有 剩余 资源 时 ， 调 度 器 会 将 这 些 资源 共享 给 其 他 资源 池 ， 而 当 该 资源 池 中 有 新 的 作业 提交 
时 ， 调 度 器 要 为 它 回收 资源 。 为 了 尽 可 能 降低 不 必要 的 计算 浪费 ， 调 度 器 采用 了 先 等 待 再 强制 回收 的 策略 ， 即 如 果 等 待 一 段 时 间 
后 尚 有 未 归还 的 资源 ， 则 会 进行 资源 抢占 : 从 那些 超额 使 用 资源 的 队列 中 杀 死 一 部 分 任务 ， 进 而 释放 资源 。 
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口 负载 均衡 : Fair Scheduler 提 供 了 一 个 基于 任务 数目 的 负载 均衡 机 制 。 该 机 制 尽 可 能 将 系统 
上 。 此 外 ， 用 户 也 可 以 根据 自己 的 需要 设计 负载 均衡 机 制 。 




















的 任务 均匀 分 配 到 各 个 节点 


















































口 任务 延 时 调度 ，Fair Scheduler 提 供 了 一 种 基于 延 时 等 待 的 调度 机 制 以 提高 任务 的 数据 本 地 性 。 该 机 制 通过 暂时 减少 个 别 作 
业 的 资源 量 而 提高 系统 整体 吞吐 率 。 













































































口 降低 小 作业 调度 延迟 : 由 于 采用 了 最 大 最 小 公平 算法 ， 小 作业 可 以 优化 获取 资源 并 运行 完成 。 
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10.5.1 Fair Scheduler 功 能 介绍 


























与 Capacity Scheduler 类 似 ，Fair Scheduler 也 是 一 个 多 用 户 调度 器 ， 它 同样 添加 了 多 层级 别 的 资源 限制 条 件 以 更 好 地 让 多 用 户 共 
享 一 个 Hadoop 集 群 ， 比 如 队列 资源 限制 、 用 户 作 业 数 目 限 制 等 。 然 而 ， 由 于 Fair Scheduler 增 加 了 很 多 新 的 特性 ， 因 此 它 的 配置 选 
项 更 多 。 为 了 能 够 更 详尽 地 了 解 Fair Scheduler 的 功能 ， 我 们 从 它 的 配置 文件 讲 起 。Fair Scheduler 的 配置 选项 包括 两 部 分 ， 其 中 一 部 
分 在 mapred-site.xml 中 ， 另 外 一 部 分 在 自己 的 配置 文件 中 ， 默 认 情 况 下 为 存放 在 con 佣 录 下 的 但 ir-scheduler.xml。 






































= 



































































































































pals 





1. 配 置 文件 mapred-site.xml 
































启用 Fair Scheduler 时 ， 可 在 配置 文件 mapred-site.xml 中 增加 以 下 几 个 配置 选项 (其 中 ，mapred.jobtracker.taskScheduler 是 必 填 
的 ， 其 他 自选 ) 。 
































口 mapred. jobtracker.taskScheduler: 采用 的 调度 器 所 在 的 类 ， 即 为 org.apache.hadoop.mapred.FairScheduler。 











口 mapred. fairscheduler.poolnameproperty: 资源 池 命 名 方式 ， 包 含 以 下 三 种 命名 方式 。 











Ouser.name: 默认 值 ， 一 个 UNIX 用 户 对 应 一 个 资源 池 。 


























Ogroup.name: 一 个 UNIX 用 户 组 对 应 一 个 资源 池 。 


O 〇 mapred.job.queue.name: 一 个 队列 对 应 一 个 资源 池 。 如 果 设 置 为 该 值 ， 则 与 Capacity Scheduler 一 样 。 














口 mapred. fairscheduler.allocation.fle: Fair Scheduler 配 置 文件 所 在 位 置 ， 默 认 是 SHADOOP_HOME/conffair-scheduler.xml。 












































口 mapred. fairscheduler.preemption: 是 否 支持 资源 抢占 ， 默 认为 人 lse。 




















口 mapred. fairscheduler.preemption.only.log: 是 否 只 打印 资源 抢占 日 志 ， 并 不 真正 进行 资源 抢占 。 打 开 该 选项 可 用 于 调试 。 





























口 mapred. fairscheduler.assignmultiple: 是 否 在 一 次 心跳 中 同时 分 配 Map Task 和 ReduceTask， 默 认为 true。 








口 mapred. fairscheduler.assignmultiple.maps: 一 次 心跳 最 多 分 配 的 Map Task 数 目 ， 默 认 是 -1， 表 示 不 限制 。 





Dmapred. fairscheduler.assignmuttiple.reduces: 一 次 心跳 最 多 分 配 的 Reduce Task 数 目 ， 默 认 是 -1， 表 示 不 限制 





= 
o 





口 mapred. fairscheduler.sizebasedweight: 是 否 按 作业 大 小 调整 作业 权重 。 将 该 参数 置 为 tue 后 ， 调 度 器 会 根据 作业 长 度 〈 任 务 数 
H) 调整 作业 权重 ， 以 让 长 作业 获取 更 多 资源 ， 默 认 是 false。 











口 mapred. fairscheduler.locality.delay.node: 为 了 等 待 一 个 满足 node-local 的 slot， 作 业 可 最 长 等 待 时 间 。 


口 mapred. fairscheduler.locality.delay.rack: 为 了 等 待 一 个 满足 rack-local 的 slot， 可 最 长 等 待 时 间 。 


























口 mapred. fairscheduler.loadmanager: 可 插 拔 负载 均衡 器 。 用 户 可 通过 继承 抽象 类 LoadManager 实 现 一 个 负载 均衡 器 ， 以 决定 每 
个 TaskTracker 上 运行 的 Map Task 和 Reduce Task 数 目 ， 默 认 实 现 是 CapBasedLoadManager， 它 将 集群 中 所 有 Task 按 照 数 量 平 均 分 配 
到 各 个 TaskTracker 上 。 


















































口 mapred. fairscheduler.taskselector: 可 插 拔 任务 选择 器 。 用 户 可 通过 继承 TaskSelector 抽 象 类 实现 一 个 任务 选择 器 ， 以 决定 对 于 
给 定 一 个 TaskTracker， 为 其 选择 作业 中 的 哪个 任务 。 有 具体 实现 时 可 考虑 数据 本 地 性 ， 推 测 执行 等 机 制 。 默 认 实现 是 
DefautTaskSelector， 它 使 用 了 JobInProgress 中 提供 的 算法 ， 有 具体 可 参考 第 6 章 。 




























































































口 mapred. fairscheduler.weightadjuster: 可 插 拔 权 重 调整 器 。 用 户 可 通过 实现 WeightAdjuster 接 口 编写 一 个 权重 调整 器 ， 以 动态 调 
整 运行 作业 的 权重 。 





























2. 配 置 文件 fair-scheduler.xml 





























fair-scheduler. xml Fair Scheduler 的 配置 文件 ， 管 理 员 可 为 每 个 pool 添 加 一 些 资源 约束 以 限制 资源 使 用 。 对 于 每 个 pool， 用 户 可 
配置 以 下 几 个 选项 。 








口 minMaps: 最 少 保证 的 Map sot H, Meha. 























口 maxMaps: 最 多 可 以 使 用 的 Map slot4 H - 





OminReduces: 最 少 保证 的 Reduce slot 数 目 ， 即 最 小 资源 量 。 


a 





p 





口 maxReduces: 最 多 可 以 使 用 的 Reduce slot 数 目 。 














口 maxRunningJops: 最 多 同时 运行 的 作业 数目 。 通 过 限制 该 数目 ， 可 防止 超 量 MapTask 同 时 运行 时 产生 的 中 间 输 出 结果 撑 爆 磁 
































口 minSharePreemptionTimeout: 最 小 共享 
抢占 资源 。 


Hi 


抢占 时 间 。 如 果 一 个 资源 池 在 该 时 间 内 使 用 的 资源 量 一 直 低 于 最 小 资源 量 ， 则 开始 





























口 schedulingMode: 队列 采用 的 调度 模式 ， 可 以 是 FIFO 或 者 Fair。 
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管理 员 也 可 为 单个 用 户 添加 maxRunningJobs 属 性 限制 











最 多 同时 运行 的 作业 数目 。 此 外 ， 管 理 员 也 可 通过 以 下 参数 设置 以 上 
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UO poolMaxJobsDefault: 资源 池 的 maxRunningJobs 属 性 的 默认 值 。 


























DuserMaxJobsDefaukt: 用 户 的 maxRunningJobs 属 性 的 默认 值 。 




















D 口 defautMinSharePreemptionTimeout， 资 源 池 的 minSharePreemptionTimeout 属 性 的 默认 值 。 

















口 defautPoolSchedulineMode: 资源 池 的 schedulingMode 属 性 的 默认 值 。 









































TR 


Q fairSharePreemptionTimeout: 公平 共享 量 抢占 时 间 。 如 果 一 个 资源 池 在 该 时 间 内 使 用 资源 量 一 直 低 于 公平 共享 量 的 一 
始 抢占 资源 。 





， 则 








ul 














也 


























O defàultPoolSchedulingMode: Pool 的 schedulngMode 属 性 的 默认 1 
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【实例 】 假 设 要 为 一 个 Hadoop 集 群 增加 三 个 资源 池 poolA、poolB 和 defut， 且 规定 普通 用 户 最 多 可 同时 运行 40 个 作业 ， 但 用 
户 userA 最 多 可 同时 运行 400 个 作业 ， 那 么 可 在 fir-schedulerxml 中 进行 如 下 配置 : 



































<allocations> 
<pool name="poolA"> 
<minMaps>100</minMaps> 

<maxMaps>150</maxMaps> 

<minReduces>50</minReduces> 

<maxReduces>100</maxReduces> 
<maxRunningJobs>200</maxRunningJobs> 
<minSharePreemptionTimeout > 300</minSharePreemptionTimeout> 
<weight>1.0</weight> 

</pool> 

<pool name="poolB"> 

<minMaps>80</minMaps> 

<maxMaps > 80</maxMaps> 

<minReduces>50</minReduces> 

<maxReduces>50</maxReduces> 
<maxRunningJobs>30</maxRunningJobs> 
<minSharePreemptionTimeout >500</minSharePreemptionTimeout> 
<weight>1.0</weight> 

</pool> 

<pool name="default"> 

<minMaps>0</minMaps> 

<maxMaps>10</maxMaps> 

<minReduces>0</minReduces> 

<maxReduces>10</maxReduces> 
<maxRunningJobs>50</maxRunningJobs> 
<minSharePreemptionTimeout >500</minSharePreemptionTimeout> 
<weight>1.0</weight> 

</pool> 

<user name="userA"> 

<maxRunningJobs>400</maxRunningJobs> 

</user> 

<userMaxJobsDefault >40</userMaxJobsDefault> 
<fairSharePreemptionTimeout > 6000</fairSharePreemptionTimeout> 
</allocations> 








[1] http//hadoop. apache.org/docs/stable/fair_scheduler.html 
[2] Max-Min Fairness (Wikipedia) : httpyen. wikipedia.org/wiki/Max-mimn fairness 


10.5.2 Fair Scheduler 实 现 











1.Fair Scheduler 基 本 设计 思想 







































































Fair Scheduler 核 心 设计 思想 是 基于 资源 池 的 最 小 资源 量 和 公平 共享 量 进行 任务 调度 。 其 中 ， 最 小 资源 量 是 管理 员 配 置 的 ， 而 公平 共享 
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是 根据 队列 或 作业 权重 计算 得 到 的 。 资 源 分 配 具体 过 程 如 下 : 















































步骤 1 根据 最 小 资源 量 将 所 有 系统 中 所 有 slot 分 配给 各 个 资源 池 。 如 果 某 个 资源 池 实 际 需 要 的 资源 量 小 于 它 的 最 小 资源 量 ， 则 只 需 将 
实际 资源 需求 量 分 配给 它 即 可 。 
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将 剩余 的 资源 分 配给 各 个 资源 池 。 

















在 各 个 资源 池 中 ， 按 照 作 业 权重 将 资源 分 配给 各 个 作业 ， 最 终 每 个 作业 可 以 分 到 的 资源 量 即 为 作业 的 公平 共享 量 。 其 中 ， 作 
业 权 重 是 由 作业 优先 级 转换 而 来 的 ， 它 们 的 映射 关系 如 表 10-1 所 示 。 
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R 10-1 作业 优先 级 与 作业 权重 映射 关系 











作业 优先 级 作业 权重 
VERY_HIGH 4.0 
HIGH 2.0 
NORMAL 1.0 
LOW 0.5 
VERY_LOW 0.25 








用 户 也 可 以 通过 打开 mapred.fairscheduler.sizebasedweigh 参 数 以 根据 作业 长 度 调 整 权 重 或 者 编写 权重 调整 器 动态 调整 作业 权重 。 


























【实例 】 如 图 10-7 所 示 ， 假 设 一 个 Hadoop 集 群 中 共有 100 有 slot (为 了 简单 ， 不 区 分 Map 或 者 Reduce slot) 和 四 个 资源 池 《 依 次 为 P1、 
P2、P3 和 P4) ， 它 们 的 最 小 资源 量 依次 为 : 25、19、26 和 28。 如 图 10-7 a 所 示 ， 在 某 一 时 刻 ， 四 个 资源 池 实 际 需要 的 资源 量 (与 未 运行 的 
任务 数目 相关 ) 依次 为 20、26、37 和 30， 则 资源 分 配 过 程 如 下 : 








































































































步骤 1 根据 最 小 资源 量 将 资源 分 配 各 个 资源 池 。 对 于 资源 池 P1 而 言 ， 由 于 它 实际 需要 的 资源 量 少 于 其 最 小 资源 量 ， 因 此 只 需 将 它 实 
际 需要 的 资源 分 配给 它 即 可 ， 如 图 10-7b 和 图 10-7c 所 示 。 经 过 这 一 轮 分 配 ， 四 个 资源 池 获 得 的 slo 数 目 依 次 为 : 20、19、26 和 28。 









































步骤 2 ”经 过 第 一 轮 分 配 后 ， 尚 剩余 7 个 slot， 此 时 需 按 照 权重 将 剩余 资源 分 配给 尚 需 资源 的 资源 池 P2，P3 和 P4。 不 妨 假设 这 三 个 资源 
池 的 权重 依次 为 2.0、3.0 和 2.0， 则 它们 额外 分 得 的 slot 数 目 依 次 为 >、3 和 2。 这 样 ， 如 图 10-7 d 所 示 ， 三 个 资源 池 最 终 获得 的 资源 总 量 依次 
为 : 21、29 和 30。 















































步骤 3 在 各 个 资源 池内 部 ， 按 照 作业 的 权重 将 资源 分 配给 各 个 作业 。 以 P4 为 例 ， 假 设 P4 中 有 三 个 作业 ， 优 先 级 依次 为 VERY _HIGH 


l l 
X30=20， 一 一 一 x 30=5 和 一 一 X30=5S， 
NORMAL 和 NORMAL， 则 它们 可 能 获得 的 slot 数 目 依次 为 : 4+1+1 FFIHI 4+1+1 k= MA 


即 为 对 应 作业 的 公平 共享 量 。 

















待 分 配 











404 

304 

20-4 

104 
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图 10-7 Fair Scheduler 中 的 任务 分 配 过 程 




































































注意 ”公平 共享 量 只 是 理论 上 的 资源 分 配 量 《〈 理 想 值 ) ， 在 实际 资源 分 配 时 ， 调 度 器 应 尽量 将 与 公平 共享 量 相等 的 资源 分 配给 作 














2.Fair Scheduler 实 现 






































Fair Scheduler 内 部 组 织 结构 如 图 10-8 所 示 。 涉 及 的 模块 有 : 配置 文件 加 载 模块 、 作 业 监 听 模 块 、 状 态 更 新 模块 和 调度 模块 。 下 面 分 别 
介绍 这 几 个 模块 。 








口 配 置 文件 加 载 模块 : 由 类 PoolManager 完 成 ， 负 责 将 配置 文件 人 ir-schedulerxml 中 的 信息 加 载 到 内 存 中 。 








口 作业 监听 模块 : Fair Scheduler 启 动 时 会 向 JobTracker 注 册 作 业 监 听 器 JobListener， 以 便 能 够 随时 获取 作业 变化 信息 。 





口 状态 更 新 模块 ， 由 线程 UpdateThread 完 成 ， 该 线程 每 隔 mapred.fairscheduler.update.interval (默认 是 500 毫 秒 ) 时 间 更 新 一 次 队列 和 作业 
的 信息 ， 以 便 将 最 新 的 信息 提供 给 调度 模块 进行 任务 调度 。 









































口 调度 模块 : 当 某 个 TaskTracker 通 过 心跳 请 求 任务 时 ， 该 模块 根据 最 新 的 队列 和 作业 的 信息 为 该 TaskTracker 选 择 一 个 或 多 个 任务 。 





Function 
Revocation 


jobAdded () 
















Fair Scheduler 


assignTasks () FairScheduler 


UpdateThread 


图 10-8 Fair Scheduler 内 部 组 织 结构 












JobTracker 


Josevur [00g 

















在 不 同 的 Hadoop 版 本 中 ，Fair Scheduler 调 度 算 法 实现 方式 不 同 。 这 里 介绍 两 个 版 本 的 实现 : 0.20.X 版 本 和 0.21.X/0.22.X/1.X 版 本 。 


C1) 0.20.X 版 本 






































前 面 提 到 了 作业 公平 共享 量 的 计算 方法 ， 而 调度 器 的 任务 就 是 将 与 公平 共享 量 相等 的 资源 分 配给 作业 。 在 实际 的 Hadoop 集 群 中 ， 由 
于 资源 使 用 情况 是 动态 变化 的 ， 且 任务 运行 的 时 间 长 短 不 一 ， 因 此 时 刻 保 证 每 个 作业 实际 分 到 的 资源 量 与 公平 共享 量 一 臻 是 不 可 能 的 。 
为 此 ，0.20.X 版 本 采用 了 基于 缺额 的 调度 策略 。 该 策略 采用 了 贪心 算法 以 保证 尽 可 能 公平 地 将 资源 分 配给 各 个 作业 。 
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缺额 (jobDeficit〉 是 作业 的 公平 共享 量 与 实际 分 配 到 的 资源 量 之 间 的 差 值 。 它 反映 了 资源 分 配 过 程 中 产生 的 "理想 与 现实 的 差距 ”。 调 
度 器 在 实际 资源 分 配 时 ， 应 保证 所 有 作业 的 缺额 尽 可 能 小 。 缺 额 的 基本 计算 公式 为 : 











jobDeficit=jobDeficit+ (jobFairShare-runnngTasks) xtimeDelta 




















其 中 ，jobFairShare 为 作业 的 公平 


NaF Ba» 














时 间 间 隔 。 
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际 平均 分 配 到 的 资源 


runningTasks 是 资源 池 


选 定 一 个 资源 池 后 ，Fair Scheduler 总 是 


池 的 一 致 ， 即 为 该 作业 正在 运行 的 任务 数目 
Scheduler 为 管 


从 上 面 公式 可 以 看 出 ， 作 业 缺 额 是 随 着 时 间 积 累 
如 果 在 一 段 时 间 内 


He YR 


个 获得 资 





作业 一 直 没 有 














runningTasks 为 作业 正在 运行 的 任务 数目 


源 ， 则 它 的 缺额 会 越 来 越 大 ， 最 终 人 




















ME 


并 不 能 保证 作业 时 让 
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(2) 0. 21.X/0.22.X/1.X 版 本 




















在 0.21.X/0.22.X/1.X 版 本 中 ， 同 Capacity Scheduler 一 样 ，Fair Scheduler 也 采 
一 个 作业 和 该 作业 中 的 一 个 任务 ， 但 
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选择 队列 


Fair Scheduler 选 择 队列 时 ， 在 不 同 的 条 件 下 采 



































口 当 存 在 资源 使 

















b 当 前 


= 





正在 运行 的 Task 数 目 





口 否则 ， 选 择 任务 权重 比 最 小 的 资源 池 ， 
tasksToWeightRatio=runningTasks/poolWeight 
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PN 








选择 作业 



































口 将 参数 mapred.fairscheduler.sizebasedweieht 置 为 tue， 则 计算 作业 权重 时 会 考虑 作业 长 度 ， 












































] 的 策略 稍 有 不 同 。 











用 











量 小 于 最 小 资源 量 的 资源 池 时 ， 优 先 选择 资源 使 / 


不 同 的 策略 ， 











Hki F: 












































(也 就 是 正在 使 























中 ，runningTasks 为 资源 池 中 正在 运行 的 任务 数 


N 




















与 作业 权重 的 比值 。 
理 员 提供 了 另外 两 种 改变 作业 的 权重 的 方法 : 











jobWeight=jobWeightByPriorityxlog, (runnableTasks ) 

















口 通过 实现 WeightAdjuster 接 








































































































中 ，jobWeightByPriority 是 通过 优先 级 转化 来 的 权 习 


口 ， 编 写 一 个 权 习 





fan 



































; poolWeieht 是 


runnableTasks 是 作业 了 





mè 








的 资源 池 权 如 





(对 应 实际 分 配 到 的 资源 量 ) ，timeDelta 为 缺 


的 。 在 进行 资源 分 配 时 ， 调 度 器 总 是 优先 将 空闲 资源 分 配给 当前 缺额 最 大 的 作业 。 
决 额 变 得 最 大 ， 从 而 可 以 获得 资源 。 
平 共享 量 对 应 的 资源 ， 但 如 果 所 有 作业 的 运行 时 间 足 够 长 ， 则 该 机 制 能 够 保证 每 个 作业 实 


j 率 最 低 的 资源 池 ， 即 runningTasks/minShare 最 小 的 资源 池 ， 
的 slot 数 目 )，minShare 为 资源 池 的 最 小 资源 量 。 
































但 需要 注意 的 是 ， 作 业 权 重 比 是 ! 











额 
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这 种 基于 缺额 的 调度 

















j 了 三 级 调度 策略 ， 即 依次 选择 一 个 资源 池 、 该 资源 池 中 的 




















中 资源 池 的 任务 权重 比 〈tasksToWeightRatio) 定义 如 下 : 


优先 将 资源 分 配给 资源 池 中 任务 权重 比 最 小 的 作业 ， 其 中 作业 的 任务 权重 比 的 计算 方法 与 资源 

















作业 优先 级 转换 而 来 的 。 此 外 ，Fair 





























\ 体 计算 方法 如 下 : 
































E 在 运行 和 尚未 运行 的 任务 之 和 。 





EE 调整 器 ， 并 通过 参数 mapred .fairscheduler.weightadjuster 使 之 生效 ， 此 时 ， 作 业 权 重 即 为 








WeightAdjuster 中 方法 adjustWeight 的 返回 值 。 

选择 任务 

任务 选择 策略 已 在 第 6 章 介 绍 过 了 ，Fair Scheduler 在 该 策略 基础 上 又 添加 了 延 时 调度 机 制 上 ， 具 体 见 下 一 小 节 。 

3.Fair Scheduler 优 化 机 制 

机 制 1: 延 时 调度 。 

第 6 章 中 已 讲 了 Map Task 的 数据 本 地 性 问题 。 我 们 知道 ， 提 高 Map Task 的 数据 本 地 性 可 提高 作业 运行 效率 。 为 了 提高 数据 本 地 性 ，Fair 
Scheduler KH 7 REN DARE DL: 当 出 现 一 个 空闲 slot 时 ， 如 果 选 中 的 作业 没有 node-loca] 或 者 rack-local 的 任务 ， 则 暂时 把 资源 让 给 其 他 作业 ， 
































直到 找到 一 个 满足 数据 本 地 性 的 任务 或 者 达到 一 个 时 间 闵 值 ， 此 时 不 得 不 为 之 选择 一 个 非 本 地 性 的 任务 。 


























为 了 实现 延 时 调度 ，Fair Scheduler 为 每 个 作业 j 维 护 三 个 变量 : level、wait 和 skipped， 分 别 表 示 最 近 一 次 调度 时 作业 的 本 地 性 级 别 〈0、 
1、2 分 别 对 应 node-local、rack-local 和 o 企 switch) 、 已 等 待 时 间 和 是 否 延 时 调度 ， 并 依次 初始 化 为 : j.leveF0、j.wait=0 和 j.skipped=false。 此 
外 ， 当 不 存在 node-local 任 务 时 ， 为 了 尽 可 能 选择 一 个 本 地 性 较 好 的 任务 ，Fair Scheduler 采 用 了 双 层 延迟 调度 算法 : 为 了 找到 一 个 node-local 
任务 最 长 可 等 待 W1 或 者 进一步 等 待 W2 找 一 个 rack-local 任 务 。 






































总 之 ， 当 JobTracker 从 TaskTracker 上 收 到 心跳 后 ，Fair Scheduler 按 照 以 下 算法 选择 Map Task: 








function List<Task>assignTasks (TaskTracker tt) 
taskListenull 
for each job j in allJdobs do 
if j.skipped=true do 
j.updateLocalityWaitTimes(); // 更 新 等 待 时 间 
j.skipped-false 
done 
end for 
while n.availableSlots()>0 then// 如 果 可 用 slot 数 目 大 于 0 
sort jobs using hierarchical scheduling policy 
for j in jobs qdo// 遍 历 排序 后 的 所 有 作业 
/ /查找 该 作业 中 是 否 包 含 符合 node-local 的 Map Task 
if (t=j.obtainNewNodeLocalMapTask()) ! =null then 
j.wait-0, j.level-0 
taskList.add (t) ; 
break; 
/ /查找 该 作业 中 是 否 包 含 符合 rack-local 的 Map Task 
else if (t=j.obtainNewNodeOrRackLocalMapTask()) ! =null and 
(j.level>=1 or j.wait>=W1) then 
j.wait-0, j.level-1 
taskList.add (t) 
break; 
else if j.level=2 or (j.level=1 and j.wait>=W2) or 
n level=0 and j.wait>=W1+W2) then 

.wait-0, j.level-2 
7 7 依次 查找 访 作业 中 符合 node-local, rack-local, off-switch 的 Map Task 
t=j .obtainNewMapTask () 
taskList.add (t) ; 
break; 
else 
j.skippedetrue 
end if 
end for 
end while 
return taskList 
end function 












































机 制 2， 负 载 均 衡 。 






































Fair Scheduler 为 用 户 提 供 了 一 个 可 扩展 的 负载 均衡 器 : CapBasedLoadManager。 它 会 将 系统 中 所 有 任务 按照 数量 平均 分 配 到 各 个 节点 上 
四。 当然， 用 户 也 可 通过 继承 抽象 类 LoadManager 实 现 自己 的 负载 均衡 器 。 



























































机 制 3: 资源 抢占 。 
































当 一 个 资源 池 有 剩余 资源 时 ，Fair Scheduler 会 将 这 些 资源 暂时 共享 给 其 他 资源 池 ， 而 一 旦 该 资源 池 有 新 作业 提交 ， 调 度 器 则 为 它 回 收 
资源 。 如 果 在 一 段 时 间 后 该 资源 池 仍 得 不 到 本 属于 自己 的 资源 ， 则 调度 器 会 通过 杀 死 任务 的 方式 抢占 资源 。Fair Scheduler 同 时 采用 了 两 种 
资源 抢占 方式 ;最 小 资源 量 抢占 和 公平 共享 量 抢占 。 如 果 一 个 资源 池 的 最 小 资源 量 在 一 定时 间 内 得 不 到 满足 ， 则 会 从 其 他 超额 使 用 资源 
的 资源 池 中 抢占 资源 ， 这 就 是 最 小 资源 量 抢占 ， 而 如 果 一 定时 间 内 一 个 资源 池 的 公平 共享 量 的 一 半 得 不 到 满足 ， 则 该 资源 池 也 会 从 其 他 
资源 池 中 抢占 ， 这 称 为 公平 共享 量 抢占 。 























































































































































































































































































































进行 资源 抢占 时 ， 调 度 器 会 选 出 超额 使 用 资源 的 资源 池 ， 并 从 中 找 出 局 动 时 间 最 早 的 任务 ， 再 将 其 杀 掉 ， 进 而 释放 资源 。 
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10.5.3. Fair Scheduler 与 Capacity Scheduler 对 比 





表 10-2 从 多 个 方面 对 比 了 这 两 个 调度 器 的 异同 。 通 过 这 个 表 ， 读 者 能 更 好 地 理解 Capacity Scheduler 与 Fair Scheduler 的 相同 点 和 
不 同 点 。 


表 10-2 Capacity Scheduler 与 Fair Scheduler 比较 


Capacity Scheduler Fair Scheduler 


目标 提供 一 种 多 用 户 共享 Hadoop 集群 的 方法 ， 以 提高 资源 利用 率 和 降低 集群 管理 成 本 
设计 思想 资源 按 比 例 分 配给 各 个 队列 ， 并 添加 各 种 严 | 基于 最 大 最 小 公平 算法 将 资源 分 配 


格 的 限制 以 防止 个 别 用 户 或 者 队列 独占 资源 | 给 各 个 资源 池 或 者 用 户 





是 否 支持 动态 加 载 配置 文件 
， 一 个 Task 只 能 占用 一 个 slot 





是 否 支持 大 内 存 作业 

是 否 支持 批量 调度 

本 地 性 任务 调度 优化 基于 跳 过 次 数 的 延迟 调度 基于 时 间 的 延迟 调度 
队列 间 资 源 分 配方 式 资源 使 用 率 低 者 优先 


队列 内 部 资源 分 配方 式 默认 是 先 来 先 服务 ， 但 也 支持 优先 级 默认 是 Fair， 也 支持 FIFO 





10.0 


1. 自 适应 调度 器 





其 他 Hadoop 调 度 器 介绍 
































器 。 该 调度 器 根 ] 














局 每 个 作业 会 被 分 解 成 多 个 





自 适应 调度 器 (Adaptive Scheduler) [1 是 一 种 以 用 户 期 望 运行 时 间 为 目标 的 调度 
任务 的 事实 ， 通 过 已 经 运行 完成 的 任务 的 运行 时 间 估 算 剩余 任务 的 运行 时 间 ， 进 而 使 得 该 调度 器 能 够 根据 作业 的 进度 和 剩余 时 间 




















all 


2. 自 学 习 调度 器 


自学 习 调度 器 (Learning Scheduler) 中 是 一 种 基于 贝 叶 














败 态 地 为 作业 分 配 资源 ， 以 期 望 作业 在 规定 时 间 内 运行 完成 。 


























构 Hadoop 集 群 。 








该 调度 器 选取 了 若干 个 作业 特 


该 调度 器 的 创新 之 处 是 将 贝 1 
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] 向 量 表示 〉 作 为 分 类 属性 ， 








WY 


昌 率 和 平均 内 存 利 月 





1/O 利 月 








器 ， 这 样 ， 当 某 个 TaskTracker 出 现 乘 








昌 率 等 。 这 些 





主要 有 作业 平均 CPU 利 


斯 分 类 算法 的 资源 感知 调度 器 。 与 现 有 的 调度 器 不 同 ， 它 更 适用 于 
斯 分 类 算法 应 用 到 MapReduce 调 度 器 设计 中 。 


























用 率 、 平 均 网 络 利 
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属性 值 可 通过 
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系统 获取 。 调 度 器 通过 


























DASZ 


用 户 标注 好 的 


些 作业 可 训 














会 通 








资源 时 ， 





























过 心跳 向 JobTracker 请 求 新 的 任务 ， 同 时 





[ 报 所 在 节点 的 资源 使 用 
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F 均 磁盘 


练 得 到 一 个 分 类 





言 息 


。 调 





度 器 收 到 该 信息 后 ， 会 将 所 有 作业 的 特征 向 量 作为 贝 叶 斯 分 类 器 的 输入 ， 判 断 出 当前 哪些 作业 可 在 该 TaskTracker 上 运行 ( 称 
为 good" 作 业 ) ， 哪 些 不 可 以 在 该 TaskTracker 上 运行 〈 称 为 bad" 作 业 ) ， 最 后 通过 一 个 效用 函数 从 所 有 "epod" 作 业 中 选 出 一 个 最 
合适 的 作业 。 

3 .动态 优先 级 调度 器 


在 0.21.X/0.22.X 版 本 中 ，Hadoop 引 入 了 一 个 新 的 调度 器 
户 动态 调整 自己 获取 的 资源 量 以 满足 其 服务 质量 要 求 。 
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该 调度 器 试图 把 Hadoop 集 


群 看 作 














个 提供 商品 的 买卖 市 场 ， 每 个 消费 者 有 











































































































































































































定 的 预算 购买 自 
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G rg 





sx 












































动态 优先 级 调度 器 〈Dynamic Priority Scheduler) | 。 该 调度 器 允 


的 东西 ， 且 消费 者 需 为 

















购买 某 件 商品 竞 标 ， 其 中 ， 出 价 高 的 人 可 获得 较 多 的 商品 ， 反 之 ， 出 价 少 的 人 获得 的 商品 也 少 。 由 于 市 场 中 商品 价格 是 不 断 上 下 
波动 的 ， 因 此 消费 者 可 结合 自己 的 需要 调整 自己 的 价位 以 买 入 更 多 或 者 更 少 的 产品 。 对 应 到 Hadoop 集 群 中 ，slot 是 进行 买卖 的 商 
品 ，Hadoop 用 户 是 消费 者 ， 每 个 用 户 分 配 有 一 定 的 预算 ， 在 任何 一 个 阶段 ， 可 能 有 多 个 用 户 同时 向 Hadoop 集 群 申请 资源 ， 其 中 
出 价 高 的 用 户 获 得 的 资源 多 ， 且 申请 资源 的 用 户 越 多 ， 单 个 slot 的 价位 也 就 越 高 。 

动态 优先 级 调度 器 的 核心 思想 是 在 一 定 的 预算 约束 下 ， 根 据 用 户 提供 的 消费 率 按 比例 分 配 资源 。 管 理 员 可 根据 集群 资源 总 量 










































































































































































费 率 ， 即 



































































































































为 每 个 用 户 分 配 一 定 的 预算 和 一 个 时 间 单 元 的 长 度 〈 通 常 为 10s 一 Imin) ， 而 用 户 可 根据 自己 的 需要 动态 调整 自己 的 消 
每 个 时 间 单 元 内 单个 slot 的 价钱 。 在 每 个 时 间 单 元 内 ， 调 度 器 按照 以 下 步骤 计算 每 个 用 户 获 得 的 资源 量 : 

1) 计算 所 有 用 户 的 消费 率 之 和 p。 

2) 对 于 每 个 用 户 ;分 配 PC， 其中， si 为 用 户 鬼 消费 来 ，c 为 Hadoop 集 群 中 ot 总数。 

D 对 于 每 个 用 户 i， 从 其 预算 中 扣除 si xu ， 其 中 wt 为 用 户 正在 使 用 的 slot 数 目 。 

动态 优先 级 调度 器 也 可 作为 一 个 元 调度 器 集成 到 其 他 调度 器 〈 比 如 FIFO, Fair Scheduler 等 ) 中 ， 这 样 ， 每 个 队列 或 者 
























































可 用 资源 量 直 接 由 动态 优先 级 调度 器 如 
器 允许 用 




















户 根据 需要 《比如 完成 时 间 ) 动态 调整 资源 ， 进 而 可 以 对 作 ， 



































) 态 计算 得 到 ， 而 其 他 调度 器 只 需 负责 分 配 资源 即 可 。 相 比 




















的 控制 。 

















[1] https//Assues. apache.org/jira/browse/ MAPREDUCE-1380 


Vi AT Bae A 

















Ir 


F 其 他 调度 器 ， 动 态 优先 级 调度 


[2] https//Assues. apache.org/jira/browse/ MAPREDUCE-1439 
[3] Thomas Sandholm and Kevin Lai. Dynamic proportional share scheduling in hadoop.In JSSPP'10: 15th Workshop on Job Scheduling 
Strategies for Parallel Processing, 2010 


10.7 ”小结 







































































本 章 介 绍 了 几 种 常见 的 多 用 户 作 业 调 度 器 。 相 比 于 FIFO 调 度 器 ， 多 用 户 调度 器 能 够 更 好 地 满足 不 同 应 用 程序 的 服务 质量 要 
























































当前 主要 有 两 种 多 用 户 作 业 调 度 器 的 设计 思路 : 第 一 种 是 在 一 个 物理 集群 上 虚拟 多 个 Hadoop 集 群 ， 这 些 集群 各 自 拥有 全 套 
独立 的 Hadoop 服 务 ， 比 如 JobTracker、TaskTracker 等 ， 典 型 的 代表 是 HOD (Hadoop OnDemand) 调度 器 ;， 另 一 种 是 扩展 Hadoop 调 






















































































度 器 ， 使 之 支持 多 个 队列 多 用 户 ， 典 型 的 代表 是 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler。 本 章 分 别 对 这 两 种 调度 
器 进行 了 介绍 。 
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HOD 调 度 器 是 一 个 在 共享 物理 集群 上 管理 若干 个 Hadoop 集 群 的 工具 ， 它 可 以 帮助 用 户 在 一 个 共享 物理 集群 上 快速 搭建 若干 
个 独立 的 虚拟 Hadoop 集 群 。 由 于 该 调度 器 会 产生 多 个 独立 的 小 集群 ， 因 此 会 增加 集群 运 维 成 本 和 降低 资源 利用 率 。 




































































为 了 克服 HOD 的 缺点 ，Capacity Scheduler 和 Fair Scheduler 出 现 了 。 它 们 通过 扩展 调度 器 功能 ， 在 不 拆 分 集群 的 前 提 下 ， 将 集群 
中 的 资源 和 用 户 分 成 若干 个 队列 ， 并 为 每 个 队列 分 配 一 定量 的 资源 ， 同 时 添加 各 种 限制 以 防止 用 户 或 者 队列 独占 资源 。 由 于 这 种 
方式 能 够 保证 只 有 一 个 Hadoop 集 群 ， 因 此 可 大 大 降低 运 维 成 本 ， 同 时 很 容易 实现 资源 共享 ， 进 而 可 明显 提高 资源 利用 率 。 








































































































第 11 章 ”Hadoop 安 全 机 制 
































第 10 章 中 介绍 了 常见 的 几 种 Hadoop 多 用 户 任 务 调度 器 ， 包 括 Fair Scheduler、Capacity Scheduler 等 。 多 用 户 任务 调度 器 使 得 不 同 























需求 的 用 户 可 以 共享 一 个 Hadoop 集 群 中 的 计算 资源 和 存储 资源 ， 进 而 大 大 降低 了 运 维 成 本 且 提 高 了 系统 资源 利用 率 ， 但 同时 引 


















































出 了 一 个 亚 需 解决 的 问题 一 一 安全 问题 。 由 于 Hadoop 缺 乏 安全 机 制 ， 当 大 量 用 户 共 享 一 个 Hadoop 集 群 时 ， 可 能 会 带 来 各 种 安全 



























































机 制 。 





本 章 将 从 Hadoop 安 全 





























隐患， 比如 普通 用 户 访问 机 密 数 据 ， 用 户 杀 死 他 人 的 作业 等 。 为 了 更 好 地 管理 Hadoop 集 群 ， 从 1.0 版 本 开始 ，Hadoop 引 入 了 安全 











设计 动机 出 发 ， 依 次 介绍 Hadoop RPC、HDFS 和 MapReduce 中 的 安全 机 制 设计 方法 。 





11.1 Hadoop 安 全 机 制 概述 





















































由 于 所 有 的 Hadoop 集 群 都 部 署 在 有 防火 墙 保护 的 局 域 网 中 且 只 允许 公司 内 部 人 员 访 问 ， 因 此 为 Hadoop 添 加 安全 机 制 的 动机 
并 不 像 传统 的 安全 概念 那样 为 了 防御 外 部 黑客 的 攻击 ， 而 是 为 了 更 好 地 让 多 用 户 在 共享 Hadoop 集 群 环境 下 安全 高 效 地 使 用 集群 




































































11.1.1 Hadoop 面 临 的 安全 问题 


在 1.0 版 本 之 前 ，Hadoop 几 乎 没有 任何 安全 机 制 ， 因 此 面临 着 各 方面 的 安全 威胁 ， 主 要 包括 以 下 几 个 方 
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(1) 缺乏 用 户 与 服务 之 间 的 认证 机 





ae 
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1) NameNode 或 者 JobTracker 缺 少 用 户 认证 机 制 : 由 于 用 户 可 以 在 应 用 程序 中 设置 自己 的 用 户 名 和 所 在 的 用 户 组 ， 这 使 得 任 














am 








sy 


2) DataNode Lz 





有 户 可 以 很 容易 伪装 成 其 他 用 户 ， 给 用 户 管理 造成 极 大 不 便 。 































































































j 户 授权 机 制 :， DataNode 上 的 Block 读 写 无 任何 访问 控制 机 制 ， 以 至 于 用 户 只 要 知道 Block ID， 就 能 够 获 











取 对 应 Block 的 内 容 ， 


3) JobTracker 上 和 缺少 











FH 








| tny Dy Be 4 — 74 DataNode_k H4% 5 A Block. 

































































(2) 缺乏 服务 与 服务 之 间 的 认证 机 秆 








j 户 授权 机 制 : 























口 任何 一 个 用 户 均 可 以 修改 或 者 杀 死 其 他 用 户 的 作业 。 





口 任何 一 个 用 户 均 可 以 修改 JobTracker 的 持久 化 状态 。 





= 











DataNode 与 NameNode、TaskTracker 与 JobTracker 之 间 缺 少 认 证 机 制 ， 以 至 于 用 户 可 以 任意 启动 DataNode 或 者 TaskTracker。 





(3) 缺乏 传输 以 及 存储 加 密 措 施 





客户 端 与 服务 器 之 间 、Slave 与 Master 之 间 的 数据 传输 采用 TCP/IP 协 议 ， 以 Socket 方 式 实现 ， 但 在 传输 和 存储 过 程 中 没有 加 / 解 
密 处 理 。Hadoop 各 节点 间 的 数据 采用 明文 传输 ， 使 其 极 易 在 传输 的 过 程 中 被 窃取 。 





此 外 ， 数 据 服 务 器 对 内 存 和 存储 器 中 的 数据 没有 任何 存储 保护 ， 在 恶意 入 侵 、 介 质 丢 失 、 维 修 等 情况 下 ， 数 据 容易 泄 





















































11.1.2 ”Hadoop 对 安全 方面 的 需求 























从 2009 年 开始 ，Yahoo! 专门 抽出 一 个 团队 解决 Hadoop 安 全 问题 ， 对 于 前 面 介 绍 的 各 种 问题 ， 最 终 期 望 能 够 满足 以 下 几 个 需 


(1) 功能 需求 


























只 有 经 授权 的 用 户 才 可 以 访问 Hadoop。 








= 





口 引入 授权 机 制 ， 




















口 任何 用 户 只 能 访问 那些 有 权限 访问 的 文件 或 者 目录 。 



































口 任何 用 户 只 能 修改 或 者 杀 死 自己 的 作业 。 








防止 未 经 授权 的 服务 接 入 Hadoop 集 群 。 
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口服 务 与 服务 之 间 引 入 权限 认证 机 制 ， 



































口 新 引入 的 安全 机 制 应 对 用 户 透明 ， 且 用 户 可 放弃 使 用 该 机 制 以 保证 向 后 兼容 。 

















(2) 性 能 需求 














引入 安全 机 制 后 带 来 的 开销 应 在 可 接受 范围 内 。 











11.1.3 Hadoop 安 全 设计 基本 原则 





C1) 作为 一 种 可 选 方案 














考虑 到 引入 Hadoop 安 全 机 制 会 给 运 维 人 员 带 来 一 定 的 麻烦 ， 且 3 

































































不 是 所 有 Hadoop 集 群 都 需要 安全 机 制 ， 因 此 ，Hadoop 中 的 





安全 机 制 应 是 可 配置 的 ， 默 认 情 况 下 与 现 有 方案 〈 简 单 基 于 操作 系统 的 认证 机 制 ) 保持 一 致 。 











(2) 无 须 显 式 输入 密码 




















为 了 保证 Hadoop 的 易 用 性 ，Hadoop 的 安全 机 制 不 应 让 用 























(3) 保持 向 后 兼容 




















当前 很 多 应 用 程序 运行 于 不 同 版 本 的 Hadoop 集 群 中 ， 引 入 Hadoop 安 全 机 制 后 应 不 影响 它们 的 功能 ， 比 如 HFTP 叫 应 可 以 在 带 



































和 不 带 安全 机 制 的 集群 中 复制 数据 。 











为 了 增强 Hadoop 的 安全 性 ， 从 2009 年 起 ，Apache 专 门 抽出 一 个 团 




















1.0 版 本 中 加 入 了 Kerberos !2! 身份 认证 和 基于 ACL (Access Control List) 的 服务 访问 控制 机 制 。 


[1] httpyphadoop. apache.org/docs/hdfs/current/hftp. html 
[2] httpy/web. mit.edw/kerberos/ 





























户 显 式 地 输入 密码 。 























队 ， 为 Hadoop 增 加 安全 认证 和 授权 机 制 ， 在 Apache Hadoop 

































































11.2 ”基础 知识 
Hadoop RPC 中 采用 了 SASL (Simple Authentication and Security Layer， 简 单 认 证 和 安全 层 ) 进行 安全 认证 ， 有 具体 认证 方法 涉及 
DIGESTMD5 和 Kerberos 两 种 。 本 节 详 细 介 绍 SASL、DIGESTMD5 和 Kerberos 的 基本 概念 和 原理 。 


11.2.1 


1.SASL 


安全 认证 机 制 














SASIL 是 一 种 





成 这 方面 的 工 














SASLX FF Z F! 

















作 。 


来 扩充 CS 模式 验证 能 力 的 认证 机 制 。 
SMTP (Simple Mail Transfer Protocol， 简 单 邮 件 传 输 协 议 ) 在 定义 之 初 没 有 考虑 到 











它 的 核心 思想 是 把 用 








户 认 证 和 安全 传输 从 应 用 程序 中 隔离 出 来 。 比 如 





























DPLAIN: 最 简单 的 机 制 ， 但 同时 也 是 最 危险 的 机 制 ， 


DDIGESTMD5: 这 是 一 种 HITP Digest 兼 容 的 安全 机 制 ， 











认证 方法 ， 





主要 包括 以 下 几 种 。 











口 ANONYMOUS: 无 须 认证 。 























>H 





na 

















用 户 认 证 等 问题 ， 现 在 SMTP 可 











以 使 用 SASIL 来 完 





为 信息 采用 明文 密码 方式 传输 。 














基于 MD5， 可 以 提供 数据 























的 安全 传输 层 。 这 是 方便 性 和 安全 性 结合 


























































































































个 密 钥 ， 而 且 该 密 钥 不 通过 网 络 











组 信息 ) 开始 ， 客 户 端 使 用 此 :质询 ?与 密 钥 计算 出 一 个 应 答 。 不 同 的 ' 质 








大 | 








此 ， 服 务 器 端 只 要 比较 客 
















































































得 最 好 的 一 种 方式 ， 也 是 SASI 默 认 采 用 的 方式 。 使 用 这 种 机 制 时 ， 客 户 端 与 服务 器 端 共 享 同 

千 输 。 验 证 过 程 是 从 服务 器 端 先 提出 “质询 ”( 实 际 上 是 

询 ”， 不 可 能 计算 出 相同 的 应 答 ， 且 任何 拥有 密 钥 的 一 方 ， 都 可 以 用 相同 的 “质询 ”算出 相同 的 应 答 。 
户 端 返回 的 应 答 与 自己 算出 的 应 答 是 否 相 同 ， 就 可 以 知道 客户 端 所 拥有 的 密 钥 是 否 正确 。 由 

输 ， 所 以 不 怕 网 络 窃取 。 





DGSSAPI: Generic Security Services Application Program Interface ( 通 
IETF (Internet Engineering Task Force， 互 联网 工程 任务 组 ) 标准 化 。 由 于 
GSSAPI 都 暗 指 Kerberos 实 现 。 我 们 将 在 下 一 小 节 对 Kerberos 进 行 详 


2.JAAS 


JAAS (Java Authentication and Authorization Service, Java 认 订 
Oo Java 2 安全 框架 提供 的 是 基于 代码 源 的 存 取 控 和 
此 ，JAAS 是 Java 安 全 编程 的 一 个 重要 补充 。 随 着 Internet 安 全 问题 越 来 越 受 到 重视 ，JAAS 在 Java 应 用 编程 中 得 


的 编程 接 
























































于 真正 的 密 钥 并 没有 通过 网 络 进行 传 




















用 安全 服务 应 



































介绍 。 














FE 和 授权 服务 ) 是 SUN 公 司 为 了 增强 Java 2 安全 
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用 和 和 
最 主要 的 实现 是 基于 Kerberos 的 ， 所 以 一 般 说 到 








序 接口 ) 。GSSAPI 本 身 是 一 套 API， 由 


At + 
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到 了 越 来 越 广泛 的 应 
















































































































































































JAAS 主 要 由 认证 和 授权 两 大 部 分 构成 。 认 证 就 是 简单 地 对 一 个 实体 的 身份 进行 判断 ， 而 授权 则 是 向 实体 授予 对 数据 资源 和 
信息 访问 权限 的 决策 过 程 。 从 1.4 版 本 开始 ，JDKE 已 经 开始 集成 JAAS。 

JAAS 认 证 通过 插件 的 形式 工作 ， 这 使 得 Java 应 用 程序 独立 于 底层 的 认证 技术 ， 应 用 程序 可 以 使 用 新 的 或 经 过 修改 的 认证 技术 
而 不 需要 修改 应 用 程序 本 身 。 应 用 程序 通过 实例 化 一 个 登录 上 下 文 对 象 来 开始 认证 过 程 ， 这 个 对 象 根 据 配 置 决定 采用 哪个 登录 模 
块 ， 而 登录 模块 决定 了 认证 技术 和 登录 方式 。 一 个 比较 典型 的 登录 方式 是 提示 输入 用 户 名 和 口令 ， 其 他 登录 方式 还 有 读 入 并 核实 
声音 或 指纹 样本 。 





JAAS 的 核心 类 可 以 分 为 公 
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类 、 认 证 类 和 授权 类 三 部 分 。 


中 ， 


公共 类 包括 Subject、Principal、Credential 三 个 类 ;， 认证 类 包 


括 LoginContext、LoginModule、CallbackHandler 和 Callback 四 个 类 ;， 授权 类 包括 Polcy、AuthPermission 和 PrivateCrtxlentialPermission 三 个 














































































































































































































































































































类 。 在 Hadoop 中 仅 用 到 了 公共 类 和 认证 类 ， 接 下 来 我 们 分 别 对 其 进行 介绍 。 

d) 公共 类 

公共 类 是 由 JAAS 认 证 和 授权 的 部 分 共同 使 用 的 类 。 其 中 Subject 类 最 关键 ， 它 代表 某 个 整体 的 一 组 相关 信息 ， 这 个 整体 可 以 
是 一 个 人 或 其 他 对 象 ， 而 相关 信息 则 包括 这 个 整体 的 标识 (Principal) 、 公 有 凭据、 私有 凭据 等 。JAAS 的 标识 类 必须 实现 
java.security.Principal 接 口 ， 但 凭据 (Credential〉 类 可 以 是 任何 对 象 。 

Subject% 

应 用 程序 首先 要 对 请 求 的 来 源 进 行 认证 ， 然 后 才能 对 该 请 求 源 访问 的 资源 进行 授权 。JAAS 框 架 定义 “主题 这 个 术语 代表 请 
求 源 。 主 题 可 以 是 任何 实体 ， 如 一 个 人 或 一 项 服务 。 一 旦 通过 了 认证 ， 主 题 就 和 相关 的 标识 联系 在 一 起 。 标 识 可 以 使 不 同 主题 之 
间 相 互 区 别 。 一 个 主题 可 以 具有 多 个 标识 ， 例 如 ， 一 个 人 可 以 有 一 个 名 字 标 识 和 一 个 身份 证 号 标识 。 主 题 也 可 以 拥有 与 安全 相关 
的 属性 ， 这 些 属性 被 称 为 凭据 。 需 要 特殊 保护 的 凭据 ， 如 私 钥 ， 储 存在 私有 凭据 集合 中 ;而 可 以 公开 的 凭据 ， 如 公共 证 书 ， 则 储 
存在 公共 的 凭据 集合 中 。 

主题 类 有 以 下 几 个 比较 重要 的 方法 : 





public Set getPrincipals(); 
public static Object doAs (final Subject subject, final PrivilegedAction action) ; 
主题 身份 执行 action 实 例 的 run 方 法 ， 如 果 正 


// 以 某 一 


























// 返 回 所 有 标识 ; 








































































































PUT, ike 








返回 从 run 方法 所 返回 的 对 象 





























































































































































































































































































































Principa% 

一 个 Principal 对 象 可 以 和 一 个 Subject 对 象 关联 ， 用 于 区 别 不 同 的 主题 〈Subjecty) 。 用 户 自 定 义 的 Principal 类 必须 实现 Principal 和 
Serializable 接 口 。 我 们 可 以 用 Principal 类 提供 的 getPrincipals 方 法 得 到 和 更 新 与 一 个 主题 相 联 系 的 标识 。 

Credential 类 

Credential 类 通常 用 于 实现 一 个 凭据 。 和 凭据 通常 分 为 两 种 ， 分 别 是 公共 和 私有 凭据。 核心 JAAS 类 库 没 有 对 公共 和 私有 凭据 类 
做 出 规定 ， 所 以 任何 Java 类 都 能 代表 凭据。 但 一 般 情 况 下 ， 建 议 作为 凭据 的 类 应 该 实现 Reffeshable 和 Destroyable 两 个 接 
Refieshable 接 口 可 以 使 凭据 能 够 自我 刷新 ， 而 Destroyable 接 口 提供 了 销毁 凭据 中 内 容 的 功能 

(2) 认证 类 

对 一 个 主题 进行 认证 需要 以 下 步 又 : 

步骤 1 应 用 程序 实例 化 登录 上 下 文 (LoginContext) 。 

步骤 2 登录 上 下 文 按照 输入 参数 及 配置 装 入 所 有 相关 的 登录 模块 。 

步骤 3 ”应 用 程序 调用 登录 上 下 文 的 Login 方 法 。 

步骤 4 Login 方 法 调用 所 有 被 装 入 的 登录 模块 。 每 个 模块 都 试图 认证 主题 。 如 果 认 证 成 功 ， 登 录 模 块 就 把 相关 的 标识 和 凭据 
关联 到 所 认证 的 主题 。 

步骤 $ 登录 上 下 文 返 回 认 证 状态 给 应 用 程序 。 

步骤 6 ”如果 认证 成 功 ， 应 用 程序 可 以 从 登录 上 下 文中 获得 被 认证 的 主题 。 











LoginContext 类 


LoginContext， 即 登录 上 








发 方法 。 





LoginModule 类 


LoginModule 类 使 开发 者 能 够 把 不 同类 


下 : 


登录 上 























下 文 类 ， 给 应 用 











程序 提供 




















下 文 依照 配置 决定 应 









































技术 的 改变 不 需要 修改 应 

















程序 本 身 。 








程序 采 








boolean login()throws LoginException; 








































































































了 认证 主题 的 基本 方法 ， 
哪些 认证 模块 ， 


型 的 认证 技术 以 插件 的 形式 加 到 应 



































并 提供 了 一 种 独立 于 底层 认证 技术 的 应 用 程序 开 
羊 ， 认 证 模块 就 以 插件 的 形式 工作 于 应 用 程序 的 底层 ， 而 认证 










































































用 程序 中 。 








该 类 中 最 重要 的 方法 是 ogin0， 定 义 如 























































































































Login 方 法 将 由 登录 上 下 文 自 动 调 用 ， 此 时 登录 模块 开始 认证 过 程 。 

CallbackHandler3& 

登录 过 程 的 身份 验证 方式 由 用 户 所 编写 的 CallbackHandler 类 决定 。 该 类 的 实现 既 可 以 是 提示 用 户 输入 用 户 名 和 密码 ， 也 可 以 
是 从 智能 卡 或 生物 特征 鉴别 设备 那里 得 到 数据 ， 或 者 简单 地 从 底层 的 操作 系统 中 抽取 用 户 信息 。 

在 某 些 情况 下 ， 登 录 模 块 必 须 和 用 户 通信 以 获得 认证 信息 ， 期 间 涉及 的 通信 过 程 如 下 : 


步骤 1 应 
































程序 提供 一 个 实现 CallbackHandler 接 











的 类 ， 




















并 把 该 类 实例 的 引用 作为 创建 登录 上 下 文 对 象 时 的 参数 。 





步骤 2 ”登录 上 下 文 接着 把 CallbackHandler 类 传 给 底层 的 登录 模块 。 


步骤 3 ”登录 模块 通过 
































这 个 引用 i 






































此 可 见 ， 
























































底层 的 登录 模块 与 




















JAAS 库 中 上 





Kerberos 等 




















， 而 Hadoop 则 主要 采用 


带 了 一 些 认 证 机 制 ， 











bo 
i:i 
x| 





























j 它 的 Handle 方 法 ， 这 样 就 可 以 从 用 户 那 里 获取 认证 信息 ， 也 可 以 把 信息 送 给 用 户 。 
户 交 互 的 方式 完全 是 由 应 用 程序 决定 的 。 




















包括 Windows NT, LDAP (Lightweight Directory Access Protocol， 轻 量 


了 Kerberos。 

















录 访 问 协 议 ) 、 











11.2.2 ”Kerberos 介 绍 


的 票据 请 求 ， 验 证 其 身份 


Kerberos 是 一 种 网 络 认 证 协议 ， 主 要 用 于 计算 机 网 络 的 身份 鉴别 。 其 特点 是 用 
证 获得 的 票据 访问 多 个 服务 。Kerberos 认 证 过 程 的 实现 不 依赖 于 


上 所 有 主机 的 物理 安全 。Kerberos 作 为 一 种 可 信任 的 第 三 方 认 训 







































































(1) Kerberos 协 议 中 的 基本 概念 





口 客户 端 〈Client) : 


口服 务 器 (Server) : 向 




















ay 























户 只 需 输 入 一 次 身份 验证 信息 就 可 以 凭借 此 验 
主机 操作 系统 的 认证 。 它 不 基于 主机 地 址 的 信任 ， 也 不 要 求 网 络 





























客户 端 就 是 用 户 ， 也 就 是 请 求 服务 的 月 


























j 户 提供 服务 的 一 方 。 





口 密 钥 分 发 中 心 (Kerberos Key Distribution Center, KDC) : 
并 对 其 授予 服务 票据 。KDCH| 






































KDC 存 储 了 所 有 客户 端 密码 和 其 他 账户 信息 ， 它 接收 来 自 客户 端 
P 包 含 认证 服务 和 票据 授权 服务 两 个 服务 。 





























EE 服务 ， 是 通过 传统 的 密码 技术 (如 共享 密 钥 〉 执 行 认证 服务 的 。 









































口 认 证 服务 (Authentication Service, AS) : 负责 检验 用 户 的 身份 。 如 果 通 过 了 验证 ， 则 向 用 户 提供 访问 票据 准许 服务 器 的 服 
务 许可 票据 。 


口 票据 授权 服务 〈Ticket Granting Service, TGS) : 负责 验证 


的 服务 许可 票据 。 


务 认证 功能 交 由 认证 服务 和 票据 授权 服务 两 


购买 电影 票 将 提高 泄露 消费 密码 的 几率 为 例 进行 类 比 。 





(2) Kerberos 认 证 过 种 


Kerberos 协 议 使 用 了 对 称 加 密 机 制 ， 


Od 
服务 i 





四 授权 票 
千 可 票据 。 
















































































口 票 据 〈Ticket) : 用 于 在 认证 服务 器 和 用 户 请 求 的 服务 之 | 























口服 务 许可 票据 : 客户 请 求 服务 时 需要 提供 的 票据 。 





EJT AA 







































































司 安 全 地 传递 用 户 的 身份 ， 同 时 也 传递 一 


























用 户 的 服务 许可 票据 。 如 果 通 过 验证 ， 则 为 用 户 提 供 访问 服务 器 








些 附加 信息 。 























i (Ticket-Granting Ticket, TGT) : 客户 访问 TGS 服务 器 需要 提供 的 票据 ， 目 的 是 为 了 : 











请 某 一 个 应 用 服务 器 的 














= 





忆 此 必然 存在 类 似 于 





















































已 条 ?万 
































] 户 Dong 经 常 到 电影 院 看 电影 。 为 了 方便 ， 他 通常 使 用 带 有 消费 密码 的 信用 卡 购买 电影 票 。 为 此 ， 

















个 服务 完成 。 为 了 阐述 Kerberos 





令 的 密 钥 。 为 了 避免 口令 在 网 络 中 不 必要 






























































讲 ， 随 着 Dong 观 





















































出 示 信 















































那么 如 何 才能 减少 出 示 信 
构 。 这 样 ， 





Dong 希 望 观看 菜场 

















j 卡 和 密码 的 次 数 昵 ? 解决 方法 之 一 就 是 在 各 个 电影 院 之 间 引 入 专门 销售 









































要 的 传递 ，Kerberos 将 服 


Ph 蕴含 的 设计 思想 ， 我 们 以 多 次 出 示 信 用 卡 消费 密码 








Dong 需 向 电影 院 售票 处 


出 示 自 己 的 信用 卡 ， 并 输入 自己 的 信用 卡 密码 才能 购买 所 需 的 电影 票 ， 从 而 持 票 入 场 。 检 票 员 会 验证 Dong 所 持 有 的 票 的 有 效 
性 ， 以 决定 是 否 允 许 Dong 进 电影 院 观看 电影 。 如 果 Dong 多 次 观看 电影 ， 则 需 多 次 出 示 自 己 的 信用 卡 及 密 
看 电影 次 数 的 增多 ， 甚 信用卡 和 密码 被 窃取 的 概率 会 增加 。 因 此 为 了 减少 信 
] 卡 和 密码 的 次 数 。 





码 购 票 A ARS o 从 概率 学 上 


用 卡 及 密码 被 窃取 的 概率 ，Dong 尽 




















“通用 电影 票 "的 售票 机 















































电影 时 ， 不 再 需要 出 示 自 己 的 信 







































































































































































用 卡 和 密码 ， 而 只 需 出 示 自 己 的 通用 景点 票 
票 ” 可 能 是 Dong 花 费 了 500 元 购买 的 ， 可 换取 20 场 具体 电影 的 一 个 凭证 。 因 此 ， 他 的 “通用 电影 票 ”并 不 是 作为 进入 电影 院 的 凭证 ， 
作为 置换 具体 电影 院 对 应 电影 票 的 凭证 ， 即 Dong 只 需 向 该 电影 院 售 票 处 出 示 该 凭证 ， 即 可 获取 一 张 进入 该 电影 院 的 电影 














































































































而 是 | 
票 。 使 用 “通用 | 
构 :“ 通 用 电影 票 " 售 票 机 构 和 1 








根据 以 上 实例 ， 我 们 可 以 引出 Kerberos 中 的 两 个 核心 服务 器 : 











包 影 票 售票 处 。 









































认证 服务 器 和 票据 许可 服务 器 ， 其 中 ， 




















H 
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即 可 。 比 如 “通用 















































Hata "可 避免 多 次 出 示 信 用 卡 及 密码 ， 从 而 减少 了 机 密 信息 被 窍 取 的 可 能 性 。 在 该 解决 方案 中 ， 存 在 两 个 核心 机 











认证 服务 器 类 似 于 “通用 












































电影 票 ” 售 票 机 构 ， 而 票据 许可 服务 器 类 似 于 电影 票 售票 处 。 如 同 “ 通 用 电影 票 "售票 机 构 不 直接 销售 电影 票 ， 认 证 服务 器 也 不 直 
接 颁 发 认证 标识 ， 而 是 只 颁发 可 以 购买 认证 标识 的 “票据 ”(TGT) 。 如 同 电影 票 售 票 处 真正 售票 ， 票 据 许 可 服务 器 才 真 正 地 颁发 
认证 标识 。 






































在 Kerberos 中 ， 当 客户 端 请 求 一 个 服务 时 ，Kerberos 协 议 认证 过 程 如 图 11-1 所 示 ， 具 体 如 下 : 














步骤 1 客户 端 向 KDC 中 的 认证 系统 发 送 服务 许可 票据 请 求 。 








步骤 2 KDC 中 的 认证 服务 器 接收 到 来 自 客户 端的 票据 请 求 后 ， 查 找 对 应 的 数据 ， 如 果 该 用 户 合法 ， 则 为 其 返回 服务 许可 票 


步骤 3 ”客户 端 向 KDC 中 的 票据 许可 服务 嚣 发送 服务 票据 请 求 。 





步骤 4 票据 许可 服务 器 检查 客户 端的 服务 许可 票据 是 否 合 法 ， 如 果 合法 ， 则 为 之 返回 服务 票据 。 


步骤 $ ”客户 端 获取 服务 许可 票据 后 ， 向 对 应 的 服务 嚣 请求 服务 。 





BRO 服务 器 检查 客户 端的 服务 票据 是 否 合法 ， 如 果 合 法 ， 则 为 之 返回 服务 器 认证 ， 从 而 可 以 安全 地 访问 服务 器 。 











Kerberos 密 钥 分 发 中 心 (KDC) 


认证 服务 器 票据 许可 服务 器 
(AS) (TGS) 





(5) 请 求 服 务 








e 
(6) 服 务 器 认证 





服务 册 


Al 11-1 Kerberos 认 证 过 程 








Hadoop 选 用 了 Kerberos 作 为 安全 认证 机 制 。 相 比 于 另外 一 种 常用 机 制 SSL〈Secure Sockets Layer) ，Kerberos 具 有 以 下 两 个 优 


口 性 能 高 : Kerberos 采 用 了 对 称 密 钥 ， 相 比 于 SSL 中 自 带 的 基于 公 钥 的 算法 要 高 效 得 多 。 











口 用 户 管理 简单 : Kerberos 依 赖 于 第 三 方 的 统一 管理 中 心 





























基于 ) 

















书 撤销 列表 ，3 


播 的 更 新 机 制 则 简单 得 多 。 比 如 ， 撤 销 




















oe 


给 各 个 服务 器 。 


















































j 户 权限 时 只 需 将 用 











户 从 KDC 的 数据 库 上 删除 即 











KDC， 管 理 员 对 用 户 的 操作 直接 作用 在 KDC 上 ， 相 比 于 SSL 中 











成 一 





可 ， 而 在 SSL 中 ， 需 要 


le 





11.3 Hadoop A Lill Se 





在 1.0.0 之 后 的 版 本 中 ，Hadoop 在 RPC、HDFS 和 MapReduce 等 方面 引入 了 安全 机 制 。 在 本 节 中 ， 我 们 将 分 别 介绍 RPC、HDFS 
和 MapReduce 中 涉及 的 安全 机 制 实现 方法 。 






























































11.3.1 RPC 
Hadoop RPC 安 全 机 制 包括 基于 Kerberos 和 令 牌 的 身份 认证 机 制 和 基于 ACL 的 服务 访问 控制 机 制 。 
1 .身份 认证 机 制 












































为 了 保证 网 络 通信 的 安全 性 ，Hadoop 中 所 有 RPC 连 接 均 采用 了 SASL。 在 11.2.1 小 节 中 ， 我 们 已 经 介绍 了 SASL 的 原理 。SASL 
本 身 不 包含 认证 机 制 ， 需 由 用 户 指定 一 个 第 三 方 实现 ， 而 Hadoop 正 是 将 Kerberos 和 DIGEST-MD5 两 种 认证 机 制 添加 到 SASL 中 实现 
了 RPC 安 全 认证 。 在 Hadoop 中 ， 除 了 NameNode， 其 他 服务 仅 支 持 Kerberos 认 证 方法 。 下 面 简要 介绍 这 两 种 认证 机 制 。 





































































































OKerberos: 客户 端 〈 如 JobClient) 获取 一 个 服务 票据 ， 然 后 才 可 以 访问 对 应 的 服务 器 。 


























UKerberos+DIGEST-MDS5: 在 这 种 机 制 中 ，Kerberos 用 于 在 客户 端 和 服务 器 端 之 间 建 立 一 条 安全 的 网 络 连接 ， 之 后 客户 端 可 
通过 该 连接 从 服务 器 端 获取 一 个 密 钥 。 由 于 该 密 钥 仅 有 客户 端 和 服务 器 端 知道 ， 因 此 ， 接 下 来 客户 端 可 使 用 该 共享 密 钥 获 取 服 务 
的 认证 。 使 用 共享 密 钥 进行 安全 认证 (使 用 DIGEST-MD5 协 议 ) 有 多 方面 的 好 处 : 由 于 它 只 涉及 认证 双方 而 不 必 涉 及 第 三 方 应 用 
《比如 Kerberos 中 的 KDC) ， 因 此 安全 且 高 效 ， 客 户 端 也 可 以 很 方便 地 将 该 密 钥 授权 给 其 他 客户 端 ， 以 让 其 他 客户 端 安全 访问 该 
服务 。 我 们 将 基于 共享 密 钥 生成 的 安全 认证 凭证 称 为 令 牌 (Token) 。 在 Hadoop 中 ， 所 有 令 牌 主要 由 identifer 和 password 两 部 分 组 
成 ， 其 中 ，identifier 包 含 了 该 令 牌 中 的 基本 信息 ， 而 password 则 是 通过 HMAC-SHA1 作 用 在 identifer 和 一 个 密 钥 上 生成 的 ， 该 密 钥 长 
度 为 20 个 字 节 并 由 Java 的 SecureRamdom 类 生成 。Hadoop 中 共有 三 种 令 牌 分别 如 下 。 
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C1) 授权 令 牌 (Delegation Token) 


























授权 令 牌 主要 用 于 NameNode 为 客户 端 进行 认证 。 当 客户 端 初 始 访问 NameNode 时 ， 如 果 通 过 Kerberos 认 证 ， 则 NameNode 会 
为 它 返 回 一 个 密 钥 ， 之 后 客户 端 只 需 借助 该 密 钥 便 可 进行 NameNode 认 证 。 为 了 防止 重启 后 密 钥 丢 失 ，NameNode 将 各 个 客户 端 对 
应 的 密 钥 持久 化 保存 到 镜像 文件 中 。 默 认 情 况 下 ， 所 有 密 钥 每 隔 24 小 时 更 新 一 次 ， 且 NameNode 总 会 保存 前 7 小 时 的 密 钥 以 保证 之 
前 的 密 钥 可 用 。 







































































(2) 数据 块 访问 令 牌 (Block Access Token) 











bt 














数据 块 访问 令 牌 主要 用 于 DataNode、SecondaryNameNode 和 Balancer 为 客户 端 存 取 数据 块 进行 认证 。 当 客户 端 向 NameNode 发 
送 文件 访问 请 求 时 ， 如 果 通 过 NameNode 认 证 以 及 文件 访问 权限 检查 ， 则 NameNode 会 将 该 文件 对 应 的 数据 块 位 置信 息 和 数据 块 访 
问 密 钥 发 送 给 客户 端 ， 客 户 端 需 凭借 数据 块 访问 密 钥 才 可 以 读 取 一 个 DataNode 上 的 数据 块 。NameNode 会 通过 心跳 将 各 个 数据 块 
访问 密 钥 分 发 给 DataNode、SecondaryNameNode 和 Balancer。 需 注意 的 是 ， 数 据 块 访问 密 钥 并 不 会 持久 化 保存 到 磁盘 上 ， 默 认 情 况 
下 ， 它 们 每 隔 10 小 时 更 新 一 次 并 通过 心跳 通知 各 个 相关 组 件 。 
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(3) 作业 令 牌 (Job Token) 




















作业 令 牌 主要 用 于 TaskTracker 对 任务 进行 认证 。 用 户 提 交 作业 到 JobTracker 后 ，JobTracker 会 为 该 作业 生成 一 个 作业 令 牌 ， 并 
写 到 该 作业 对 应 的 HDFS 系 统 目 录 下 。 当 该 作业 的 任务 调度 到 各 个 TaskTracker 上 后 ， 将 从 HDFS 上 获取 作业 令 牌 。 该 令 牌 可 用 于 任 
务 与 TaskTracker 之 间 进 行 相互 认证 (比如 Shuffle 阶 段 的 安全 认证 )。 与 数据 块 访问 令 牌 一 样 ， 作 业 令 牌 也 不 会 持久 化 保存 到 内 存 
中 ， 一 旦 JobTracker 重 新 启动 ， 就 会 生成 新 的 令 牌 。 由 于 每 个 作业 对 应 的 令 牌 已 经 写 入 HDFS， 所 以 之 前 的 仍然 可 用 。 
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相 比 于 单纯 使 用 Kerberos， 基 于 令 牌 的 安全 认证 机 制 有 很 多 优势 ， 有 具体 如 下 。 




















口 性 能 :在 Hadoop 集 群 中 ， 同 一 时 刻 可 能 有 成 千 上 万 的 任务 正在 运行 。 如 果 我 们 使 用 Kerberos 进 行 服务 认证 ， 则 所 有 任务 均 




















要 KDC 中 AS 提 供 的 TGT， 这 可 能 使 得 KDC 成 为 一 个 性 能 瓶颈 ， 而 采用 令 牌 机 币 
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而 为 过 期 令 牌 更 新 留 下 足够 时 间 。 





可 以 采用 其 他 安全 认证 机 制 蔡 换 Kerberos。 因 此 ， 基 于 令 牌 的 安全 机 制 具 有 更 好 的 灵活 性 和 扩展 性 。 
























































上 则 可 避免 该 问题 。 





口 凭证 更 新 : 在 Kerberos 中 ， 为 了 保证 TGT 或 者 服务 票据 的 安全 ， 通 常 为 它们 设置 一 个 有 效 期 ， 一 旦 它们 到 期 ， 会 对 其 进行 
更 新 。 如 果 直 接 采 用 Kerberos 验 证 ， 则 需要 将 更 新 之 后 的 TGT 或 者 服务 票据 快速 推送 给 各 个 Task， 这 必 将 带 来 实现 上 的 烦 珊 。 如 
果 采 用 令 牌 ， 当 令 牌 到 期 时 ， 只 需 延 长 它 的 有 效 期 而 不 必 重 新 生成 令 牌 。 此 外 ，Hadoop 人 允许 令 牌 在 过 期 一 段 时 间 后 仍 可 用 ， 从 




















口 安全 性 : 用 户 从 Kerberos 端 获取 TGT 后 ， 可 和 凭借 该 TGT 访 问 多 个 Hadoop 服 务 ， 因 此 ， 汇 露 TGT 造 成 的 危害 远 比 泄露 令 牌 

















口 灵活 性 : 在 Hadoop 中 ， 令 牌 与 Kerberos 之 间 没 有 任何 依赖 关系 ，Kerberos 仅 仅 是 进行 用 户 身份 验证 的 第 一 道 防线 ， 用 户 完 






































2. 服 务 访 问 控制 机 制 


























服务 访问 控制 是 Hadoop 提 供 的 最 原始 的 授权 机 制 ， 用 于 确保 只 有 那些 经 过 






































可 限制 只 允许 若干 用 户 /用 户 组 向 Hadoop 提 交 作 业 。 




















十 授权 的 客户 端 才 入 




















访问 对 应 的 服务 。 比 如 管理 员 








服务 访问 控制 是 通过 控制 各 个 服务 之 间 的 通信 协议 实现 的 。 它 通常 发 生 厂 


权限 检查 等 。 


i} 





理 














E 其 他 访问 控制 机 制 之 前 ， 比 如 文件 权限 检查 、 队 列 








为 了 启用 该 功能 ， 管 理 员 需 在 core-site.xml 中 将 参数 hadoop.security.authorization 置 为 tue， 并 在 hadoop-policy.xml 中 为 各 个 通信 协 
议 指定 具有 访问 权限 的 用 户 或 者 用 户 组 。 我 们 将 具有 访问 权限 的 用 户 或 者 用 户 组 称 为 访问 控制 列表 〈Access Control List, ACL) 。 


















































员 可 为 9 个 协议 添加 访问 控制 列表 ， 如 表 11-1 所 示 。 














表 11-1 配置 Hadoop 的 各 个 ACL 




















属性 名 称 含 又 
security.client.protocol.acl ACL for ClientProtocol， 用 于 控制 访问 HDFS 的 权限 
security.client.datanode.protocol.acl ACL for ClientDataNodeProtocol, % F*ij@q45 DataNode 之 间 的 协议 ， 主 要 


用 于 Block 恢复 


security.datanode.protocol.acl 


security.inter.datanode.protocol.acl ACL for InterDataNodeProtocol, 
security.namenode.protocol.acl ACL for NameNodeProtocol, 

通信 
security.inter.tracker.protocol.acl ACL for InterTrackerProtocol, 
security.job.submission.protocol.acl ACL for JobSubmissionProtocol， 用 于 提交 作业 、 
security.task.umbilical.protocol.acl ACL for TaskUmbilicalProtocol, 
security.refresh.policy.protocol.acl ACL for RefreshAuthorizationPolicyProtocol, 





ACL for DataNodeProtocol, DataNode 与 NameNode 之 间 的 通信 协议 
用 于 DataNode 之 间 更 新 Timestamp 


用 于 Second NameNode 与 NameNode 之 间 


用 于 TaskTracker 与 JobTracker 之 间 通 信 


查询 作业 状态 等 


用 于 Task 与 对 应 的 TaskTracker 通信 
用 于 更 新 hadoop-policy.xml 











这 9 个 ACI 的 配置 方法 相同 ， 即 每 个 ACL 可 配置 多 个 用 户 和 用 户 组 ， 用 户 之 间 和 用 户 组 之 间 都 用 “， ?分割 ， 而 用 户 和 用 户 组 















































之 间 用 空格 分 割 。 注 意 ， 如 果 只 有 用 户 组 ， 前 面 必须 保留 一 个 空格 ， 比 如 : 



































<property> 
<name>security.job.submission.protocol.acl</name> 
<value>alice, bob groupl, group2</value> 
</property> 






































上 述 代 码 表 示 用 户 alice 和 bob、 用 户 组 group1 和 group2 可 向 Hadoop 集 群 中 提交 作业 。 又 如 : 











<property> 
<name>security.client.protocol.acl</name> 
<value>group3</value> 

</property> 


























上 述 代码 表示 只 有 用 户 组 group3 可 访问 HDFS。 

















再 如 : 


sn 











<property> 
<name>security.client.protocol.acl</name> 
<value>*</value> 

</property> 

















上 述 代码 表示 所 有 用 户 和 分 组 均 可 访问 HDFS。 






































注意 ”默认 情况 下 ， 这 9 个 通信 协议 对 任何 用 户 和 分 组 开放 。 








hadoop-policy. xml 文 件 可 使 用 以 下 命令 动态 加 载 。 


口 更 新 NameNode 相 关 配 置 bin/hadoop dfsadmin-refreshServiceAcl. 











口 更 新 JobTracker 相 关 配 置 : bin/hadoop mradmin-refteshServiceAcl. 
































注意 ， 只 有 属性 securityreftesh.policyprotocolac] 指 定 的 用 户 才 可 以 更 新 该 配置 文件 。 





11.3.2 HDFS 

















客户 端 与 HDFS 之 间 的 通信 连接 























d) 客户 端 向 NameNode 发 起 的 RPC 连 接 




















NameNode 发 起 RPC 连 接 以 志 
的 认证 方法 。 








由 于 NameNode 存 储 了 系统 中 所 有 文 从 




















RCH 








F 的 元 数据 信息 ， 
F 所 属 的 数据 块 列表 。 为 了 对 客户 端 进行 安全 认证 ，Hadoop 采 用 了 Kerberos 与 授权 令 牌 相 结 合 


大 

















(2) 客户 端 向 DataNode 发 起 的 Block 传 输 连 接 





为 了 防止 客户 端 随意 从 DataNode 上 读 写 数据 ，NameNode 收 到 客 
列表 外 ， 还 会 为 每 个 Block 分 配 一 个 数据 块 访问 令 牌 。 这 样 ， 























客户 庙 








访问 令 牌 ， 只 有 通过 DataNode 验 证 后 ， 才 可 以 读 写 该 Block。 

















下 面 重 














点 介绍 授权 令 牌 和 数据 块 访问 令 牌 的 身份 认证 


(1) RA (Delegation Token) 


当 客 户 端 初始 访问 NameNode 时 ， 需 日 
可 以 凭借 该 授权 令 牌 访问 NameNode。 授 权 令 牌 可 看 作客 
保护 好 ， 任 何人 获取 了 该 密 钥 都 能 够 伪装 成 NameNode。 男 外 ， 需 要 注意 的 是 ， 











公 





考虑 到 令 牌 的 安全 性 ， 
令 牌 的 重新 申请 者 。 令 牌 的 





























认证 过 程 


























当 一 个 客户 端 使 





每 个 授权 令 牌 均 被 赋予 一 定 的 有 效 期 。 当 用 
请 者 应 以 自己 的 身份 从 NameNode 端 取得 认证 进而 为 用 
令 牌 的 NameNode 上 的 有 效 期 。 在 Hadoop 中 ， 所 有 令 牌 的 重新 申请 者 是 JobTracker， 




















重新 











授权 令 牌 向 NameNode 获 取 认 记 





步 又 1 


客户 端 将 TokenID 发 送 给 NameNode。 


TokenID={ownerID, renewerID, issueDate, 














+2922 NameNodes 使 








| TokenID#llnusterK ey 





中 TokenAuthenticator 的 计算 方法 如 下 : 





H3S Kerberos ji 3 











户 端 





























Uk, WRA 


取 NameNode 认 证 。 客 户 端 通过 认证 后 将 收 到 一 个 授权 令 牌 之 后 便 
与 NameNode 之 间 的 








部 分 组 成 ， 它 们 均 采 用 了 Kerberos 与 令 牌 相 结合 的 方法 进行 身份 认证 。 
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vit 





户 TE 


Eza 











(如 Task) 需要 读 写 一 个 文件 ， 首 先 需 要 向 












































户 端 发 送 的 文件 读 写 请 求 后 ， 除 了 为 之 返回 文件 对 应 的 Block 
从 DataNode 读 写 Block 时 ， 首 先 需 要 出 示 待 读 写 Block 对 应 的 
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享 密 钥 ， 当 在 不 安全 的 链 路 上 进行 传输 时 应 该 
只 有 通过 Kerberos 认 证 才 可 以 获取 授权 令 牌 。 



































户 从 NameNode 上 获取 到 一 个 授权 令 牌 后 ， 应 告诉 它 谁 是 
户 更 新 令 牌 。 更 新 令 牌 实际 上 就 是 延长 
它 负 责 更 新 令 牌 直到 作业 运行 完成 。 





























FE 时 ， 经 过 的 步骤 如 下 : 


其 中 TokenID 定 义 如 下 : 


maxDate, sequenceNumber } 


CNameNode 和 客户 端 共享 masterKey) ， 重 新 计算 TokenAuthenticator 和 Token。] 





sE 








TokenAuthenticator=HMAC-SHA1 (masterKey, 


TokenID) 





步骤 3 ”NameNode 检 查 
其 





内 。 





新 的 Token 是 否 合 法 。 


中 Token 计 算 方 法 如 下 : 





一 个 Token 是 合法 的 ， 


当 且 仅 当 Token 在 内 存 中 存在 ， 且 当前 时 间 仍 在 有 效 期 

















DelegationToken={TokenID, TokenAuthenticator} 

















步骤 4 ”如 果 Token 是 合法 的 ， 客 户 端 和 NameNode 分 别 将 TokenAuthenticator 作 为 密 钥 、DIGEST-MD5 作 为 认证 协议 进行 双方 认 


证 。 
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Lim 


考虑 到 令 牌 的 安全 性 ， 
JobTracker 是 授权 令 牌 的 重新 申请 者 。 当 JobTracker 为 客户 端 重新 申请 令 牌 时 ， 它 将 旧 令 牌 发 送 给 NameNode, NameNode 将 检 

















新 申请 令 牌 






































Hadoop 为 每 个 授权 令 牌 赋予 一 定 的 有 效 期 ， 当 令 牌 到 期 后 ， 需 指定 一 个 令 牌 重新 申请 者 。 在 Hadoop 

























































































查 TokenID 中 的 信息 ， 判 断 该 令 牌 是 否 满足 以 下 几 个 条 件 : 


成 的 。 














口 当 前 时 间 currentTime 





口 JobTracker 为 该 令 牌 的 重新 申请 者 ; 


口 IokenAuthenticator 正 确 ; 





























| 














小 于 最 长 有 效 期 maxDate。 





如 果 验 证 成 功 ， 则 NameNode 会 延长 该 令 牌 的 有 效 期 。 设 延长 时 间 为 renewPeriod， 则 新 的 有 效 期 为 
max{currentTime+renewPeriod, maxDate} 。 如 果 该 Token 不 在 内 存 中 ， 说 明 NameNode 可 能 因 刚 刚 启 动 丢 失 了 之 
Token， 则 NameNode 会 将 该 Token 重 新 添加 到 内 存 中 。 





(2) 数据 块 访问 令 牌 


在 原始 Hadoop 中 ，DataNode 上 没有 任何 针对 Data Block 的 访问 权限 控制 
可 以 直接 从 DataNode 上 读 取 Data Block， 用 户 也 





















































NameNode 会 定期 更 新 masterKey 并 保存 到 磁盘 上 ， 而 Token 则 仅 保 存在 内 存 中 。 


(Data Block Access Token) 














前 内 存 中 所 有 的 


























这 使 得 任何 用 户 只 要 能 够 提供 一 个 合法 的 Block ID 便 





























z| 


以 向 DataNode 上 写 入 任意 的 Data Block。 这 主要 是 HDFS 缺 






















































































乏 相 关 的 安全 机 制造 


当 用 户 需 要 读 取 某 个 文件 时 ， 首 先 将 请 求 发 送 给 NameNode, NameNode 检 查访 用户 是 否 有 该 文件 访问 权限 ， 如 果 有 ， 则 将 





该 文件 对 应 的 Block 元 信息 发 送 给 用 户 ， 这 样 ， 用 户 再 依次 从 对 应 的 TaskTracker 上 读 取 所 有 Block 便 获取 整个 文件 内 容 。 由 于 


DataNode 上 没有 任何 文件 或 者 文件 访问 权限 相关 的 概念 ， 因 此 它 不 会 对 客户 端的 Block 访 问 请 求 进行 任何 验证 。 


端 进 行 合法 性 验证 。 一 个 










































































为 了 提供 安全 的 数据 读 写 机 制 ，HDFS 增 加 了 基于 块 访问 令 牌 的 安全 认证 机 制 。 块 访问 令 牌 由 NameNode 生 成 ， 并 在 DataNode 































































































后 ， 将 文件 对 应 的 所 有 数 拉 
据 块 访问 令 牌 发 送 给 对 应 上 








































































































行 安全 验证 ， 而 只 有 通过 安全 验证 的 访问 请 求 才 可 以 获取 数据 块 。 














客户 端 可 以 缓存 来 自 NameNode 的 数据 块 访问 令 牌 ， 且 仅 当 令 牌 失效 或 令 牌 不 存在 时 才 从 NameNode 庙 














型 的 应 用 场景 如 下 : 一 个 客户 端 向 NameNode 发 送 文件 读 请 求 ，NameNode 验 证 该 用 户 具 有 文件 读 权限 
居 块 的 太 、 位 置 以 及 数据 块 访问 令 牌 发 送 给 客户 端 ， 当 客户 端 需要 读 取 某 个 数据 块 时 ， 将 数据 块 D 和 数 
和 DataNode。 由 于 NameNode 已 经 通过 心跳 将 密 钥 发 送 给 各 个 DataNode， 因 此 DataNode 可 以 对 数据 块 进 
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新 获取 。 





11.3.3 MapReduce 














MapReduce 权 限 管理 和 身份 认证 涉及 作业 提交 、 作 业 控 制 、 任 务 启动 、 任 务 运行 和 Shuffle 等 阶段 。 接 下 来 分 别 对 以 上 各 阶段 


进行 介绍 。 














(1) 作业 提交 



































] 户 提交 作业 后 ，JobClient 需 与 NameNode 和 JobTracker 等 服务 进行 通信 ， 以 进行 身份 认证 和 获取 相关 令 牌 ,具体 过 程 如 下 : 















































步骤 1 JobClient 与 NameNode 通 信 ， 通 过 Kerberos 验 证 后 可 获取 授权 令 牌 。 使 用 该 令 牌 ， 作 业 和 任务 可 以 读 写 HDFS 上 的 文 





























步骤 2 ”JobClent 将 作业 运行 相关 的 文件 ， 比 如 作业 配置 文件 job.xml、 输 入 分 片 相关 文件 job.splt 和 job.splitmetainff、 程 序 jar 包 
等 ， 上 传 到 HDFS 的 目录 $ {mapreduce.jobtracker.staging.root.dir}/$ {user}/.staging/$ {jobid} 下 《其 中 $f{mapreduce.jobtracker.staging.root.dir} 
为 ${hadoop.tmp.dir}/mapred/staging) 。 为 了 保证 该 目录 中 的 文件 不 会 被 其 他 用 户 窃取 ，Hadoop 将 其 访问 权限 设置 为 700。 

























































































步骤 3 ”JobClient 通 过 RPC 将 作业 文件 目录 和 授权 令 牌 发 送 给 JobTiracker。 



































步骤 4 ”JobTracker 为 作业 生成 作业 令 牌 ， 连 同 HDFS 的 授权 令 牌 一 并 写 入 $ {mapred.system dir}/${jobid}/job-info/jiobToken 中 
(${mapred. system dir} RYE W$ {hadoop.tmp.dir} /mapred/system) ， 同 时 将 其 访问 权限 设置 为 700。 









































注意 ”JobTracker 对 作业 进行 初始 化 时 ， 需 要 从 HDFS 上 读 取 job.splitmetainfb 文 件 ， 此 时 ， 它 是 借用 作业 的 授权 令 牌 完成 的 。 





(2) 作业 控 币 
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j 户 提交 作业 时 ， 可 通过 参数 mapreduce.job.acLview-job 指 定 哪 些 用 户 或 者 用 户 组 可 以 查看 作业 状态 ， 也 可 以 通过 参数 
mapreduce.job.ack-modify-job 指 定 哪些 用 户 或 者 用 户 组 可 以 修改 或 者 杀 掉 job。 









































(3) 任务 启动 








TaskTracker 收 到 JobTracker 分 配 的 任务 后 ， 如 果 该 任务 来 自 某 个 作业 的 第 一 个 任务 ， 则 会 进行 作业 本 地 化 : 将 任务 运行 相关 
的 文件 下 载 到 本 地 目录 下 ， 其 中 ， 作 业 令 牌 文件 会 被 写 到 ${fmapred.localdiry /ttprivate/taskTracker$ {user} /jobcache/$ {jobid} /jobToken 
目录 下 。 由 于 只 有 该 作业 的 拥有 者 可 以 访问 该 目录 ， 因 此 令 牌 文件 是 安全 的 。 此 外 ，Task 要 使 用 作业 令 牌 向 TaskTracker 进 行 安全 
认证 ， 以 请 求 新 的 任务 或 者 汇报 任务 状态 。 














































































































(4) 任务 运行 



































增加 安全 机 制 之 前 ，Hadoop 中 所 有 用 户 的 任务 均 是 以 启动 Hadoop 的 用 户 的 身份 启动 的 ， 也 就 是 说 ， 虽 然 各 个 用 户 以 不 同 身 
份 提交 作业 ， 但 最 终 在 各 个 节点 上 是 以 同一 个 用 户 运行 身份 运行 的 。 很 显然 ， 这 是 不 安全 的 ， 比 如 任何 一 个 用 户 可 以 很 容易 杀 掉 
另外 一 个 用 户 的 任务 。 




























































































为 了 解决 该 问题 ，Hadoop 应 以 实际 提交 作业 的 那个 用 户 身 份 运行 相应 的 任务 。 为 此 ，Hadoop 用 C 程 序 实 现 了 一 个 setuid 程 序 
以 修改 每 个 任务 所 在 JVM 的 有 效用 户 ID。 若 要 启用 该 功能 ， 管 理 员 首 先 需 编译 setuid 程 序 ， 并 将 生成 的 可 执行 程序 存放 到 
$HADOOP HOMEbin 目 录 下 ， 然 后 在 配置 文件 中 将 mapred.task.tracker.task-controller 设 置 为 
org.apache.hadoop.mapred.LinuxTaskController， 同 时 修改 配置 文件 task-controller.c 人 多。 
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C5) Shuffle 











在 MapReduce 中 ， 一 个 作业 的 Map Task 将 结果 直接 写 到 TaskTracker 的 本 地 磁盘 上 ， 而 Reduce Task 则 通过 HTTP 从 TaskTracker 上 

















获取 数据 。 在 添加 安全 机 4 
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之 前 ， 任 何 用 户 只 要 通过 URL 即 可 获取 任意 一 个 Map Task 的 中 间 输 出 结果 ， 比 如 可 使 用 以 下 URIL 获 取 
节点 node100 上 作业 job 201211011150 10219 的 第 0 个 Map Task 的 第 0 片 数据 : 









































http://node100: 33580/mapOutput?job=job 201211011150 | 
reduce=attempt_201211011150_ 10219 r 000000 0 





0219&map=attempt_201211011150_10219 m 000000_0& 
为 了 解决 该 问题 ， 





Hadoop 在 Reduce Task 与 TaskTracker 之 闻 的 通信 机 制 上 添加 了 双向 认证 机 制 ， 以 保证 有 上 且 
Reduce Task 才 能 够 读 取 Map Taski 4 


No 























P 间 结果 。 该 双向 认证 是 以 它们 之 间 共 享 的 作业 令 牌 为 基础 站 

















仅 有 同 作业 的 











TaskTracker 对 Reduce Task 认 证 








Reduce Task 从 TaskTracker 上 获取 数据 之 前 ， 先 要 将 HMAC-SHAL CURL, JobToken) 发 送 给 TaskTracker TaskTracker 利 
保存 的 作业 令 牌 计算 HMAC-SHA1， 然 后 比较 该 
































与 Reduce Task 发 送 过 来 的 是 否 一 致 ， 如 果 一 致 ， 则 通过 身份 认 记 
Reduce Task 对 TaskTracker 认 证 





























为 了 防止 伪装 的 TaskTracker 向 Reduce Task 发 送 数据 ，Reduce Task 也 需要 对 TaskTracker 进 行 认 训 
证 成 功 后 ， 需 使 用 Reduce Task 发 送 过 来 的 HMAC-SHAI1 值 与 作业 令 路 
































































































































E。 TaskTracker 对 Reduce Task 认 
计算 一 个 新 的 HMAC-SHA1， 经 Reduce Task 验 证 后 ， 双 方 认 
证 才 算 通过 ， 此 时 才 可 以 正式 传送 数据 。 
(6) Web UI 
在 Hadoop 中 ， 任 何 用 户 均 可 以 通过 Web 界 面 观 察 整个 集群 的 资源 使 用 情况 和 每 个 作业 的 运行 状态 ， 这 很 显然 缺乏 必要 的 安全 
认证 机 制 。 考 虑 到 Hadoop 中 的 界面 是 基于 Jetty 实 现 的 ， 因 出 








上 ， 为 了 实现 安全 认证 机 玮 

















制 ， 需 在 Jetty 中 添加 相应 的 模块 。Kerberos 中 
已 经 自 带 了 Web 浏 览 器 访问 认证 机 制 SPNEGO (Simple and Protected GSS-API Negotiation) 。Hadoop 1.0 直 接 采 月 


目 了 该 认证 机 制 。 














11.3.4 上层 服 务 

















在 Hadoop 中 ， 很 多 上 层 服务 充当 Hadoop 服 务 的 请 求 代理 ， 比 如 Oozie、Hive 等 。 前 面 提 到 ，Hadoop 添 加 安全 认证 机 制 后 ， 所 





























有 访问 Hadoop 的 代理 服务 均 需 要 





IAJ 





Hadoop 的 各 个 服务 〈 类 似 于 Linux 中 的 sudo 命 令 )》 。 这 些 超级 用 
































能 以 其 他 用 户 的 身份 访问 Hadoop 服 务 。 当 超级 用 
接 ， 如 果 满 足以 下 条 件 ，Hadoop 将 接受 连接 请 求 : 





















































口 请 求 用 户 属于 超级 





JP. 
































口 用 户 所 在 的 机 器 人 * 在 安全 人 P 列 表 内 。 


























凭证 。 为 此 ，Hadoop 引 入 了 “超级 用 户 ” 的 概念 ， 这 些 用 户 可 以 以 其 他 人 的 身份 访问 
户 访 问 Hadoop 服 务 时 ， 首 先 自己 需 能 够 经 过 Kerberos 认 证 ， 然 后 才 
户 希 望 与 Hadoop 的 某 个 服务 建立 RPC 连 接 时 ， 首 先 需要 使 用 doAs 方 法 设置 该 连 






































下 面 以 Oozie 为 例 说 明 上 层 服 务 安全 访问 Hadoop 服 务 的 方法 。 假 设 Hadoop 中 包含 两 个 用 户 : 超级 用 户 ooze 和 普通 用 户 dong。 

















其 中 ，oozie 有 Kerberos 凭 证， 而 dong 没 有 。 当 
Hadoop 上 。 而 实际 运行 作业 时 ，oozie 想 以 普通 用 
份 启 动 ， 且 以 dong 身 份 访 问 HDFS 上 文件 ， 即 用 
























































C1) 代码 





























为 了 让 超级 伪装 成 普通 
Hadoop 服 务 访问 操作 则 放 在 代理 ug 的 doAs 方 法 中 ， 











| FP oozie#é 42 ith, 















































户 将 作业 提交 到 oozie 上 后 ，oozie 将 以 超级 用 户 oozie 身 份 进一步 将 作 \ 
户 dong 的 身份 访问 HDFS 和 MapReduce， 也 就 是 说 ， 所 有 任务 需 以 
户 oozie 伪 装 成 了 用 


] 户 dong， 需 使 用 oozie 的 Kerberos 和 凭证 登录 系统 3 
具体 如 下 : 


























提交 到 


] 户 dong 的 身 



































户 dong。 












































为 dong 创 建 一 个 代理 ugi， 而 真正 的 








UserGroupInformation ugi= 
UserGroupInformation.createProxyUser (user, 
UserGroupInformation.getLoginUser()) ; 

ugi.doAs (new PrivilegedExceptionAction<Void> () { 
public Void run()throws Exception{ 

// 提 交 作 业 
JobClient jc=new JobClient (conf) ; 
jc.submitJob (conf) ; 

// 访 问 HDFS 

FileSystem fs=FileSystem.get (conf) ; 
fs.mkdir (someFilePath) ; 








} 





(2) 配置 














i} 














理 员 需 要 在 配置 文件 中 指定 超级 























<property> 
<name>hadoop.proxyuser.oozie.groups</name> 
<value>groupl, group2</value> 

< description> 人 允许 超级 用 户 oozie 冒 充 
</property> 

<property> 
<name>hadoop.proxyuser.oozie.hosts</name> 
<value>hostl, host2</value> 









































户 组 groupl 和 group29 





FP 的 所 有 





<description>oozie 只 能 从 host1 和 host2 上 发 起 连接 以 冒充 其 























j 户 oozie 可 伪装 成 的 所 有 用 户 ， 同 时 限制 oozie 所 在 的 一， 有 具体 如 下 : 























户 <</dqescription> 











j 户 之 /description> 








</property> 








如 果 管 理 员 不 进行 以 上 配置 ， 则 认为 不 允许 任何 用 户 伪装 成 其 他 用 户 。 























11.4 应 用 场景 总 结 

















当 管理 员 配 置 一 个 安全 的 Hadoop 集 群 时 ， 一 般 会 创建 两 个 用 户 : hd 信和 mapreduce， 并 为 其 添加 Kerberos 认 证 ， 以 让 它们 分 别 
安全 地 启动 HDFS 服 务 和 MapReduce 服 务 。 在 一 个 安全 的 Hadoop 集 群 中 ， 各 种 应 用 场景 涉及 的 安全 认证 过 程 如 下 。 






























































11.4.1 文件 存 取 














me 


节理 员 需 要 在 NameNode 和 DataNode 所 在 节点 上 为 用 户 hdB@ 添 加 Kerberos 认 证 ， 这 样 ， 管 理 员 以 hd 身份 启动 NameNode 和 
避免 非法 NameNode 或 者 DataNode 接 入 Hadoop 集 群 。 
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DataNode, 可 














一 个 应 用 程序 从 HDFS 上 存 取 文件 涉及 的 安全 认证 如 图 11-2 所 示 。 整 个 过 程 涉 及 Kerberos 认 证 及 Delegation Token 和 Block Access 
Token 两 种 令 牌 ， 其 中 ，Kerberos 认 证 用 于 应 用 程序 第 一 次 访问 NameNode 时 进行 身份 认证 ， 通 过 认证 之 后 ，NameNode 会 为 之 分 
fic Delegation Token 或 者 Block Access Token， 今 后 只 需 使 用 令 牌 访问 NameNode 或 者 从 DataNode 上 存 取 数 据 即 可 。 













































































MapReduce 


Application 
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11-2 文件 存 取 过 程 中 涉及 的 安全 认证 











11.4.2 ”作业 提交 与 运行 


fo 


理 员 需 要 在 JobTracker 和 TaskTracker 所 在 节点 上 为 用 户 mapreduce 添 加 Kerberos 认 证 ， 这 样 ， 管 理 员 以 mapreduce 身 份 启动 JobTracker 和 
TaskTracker， 可 避免 非法 JobTracker 或 者 TaskTracker 接 入 Hadoop 集 群 。 








mÈ 














aur 











一 个 应 用 程序 从 作业 提交 到 运行 涉及 的 安全 认证 如 图 11-3 所 示 。 整 个 过 程 涉 及 Kerberos 认 证 及 Delegation Token, Block Access Token, 
JobToken 三 种 令 牌 。Kerberos 认 证 、Delegation Token 和 Block Access Token 的 作用 与 11.4.1 节 中 类 似 。JobToken 创 建 于 JobTracker 端 ， 并 分 发 到 
各 个 TaskTracker 以 用 于 Task 与 TaskTracker 之 间 的 安全 认证 。 
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图 11-3 作业 提交 与 运行 过 程 中 涉及 的 安全 认证 








11.4.3 上层 中 间 件 访问 Hadoop 








Hadoop 有 很 多 上 层 中 间 件 ， 比 如 Ooze、Hive 等 。 它 们 通常 采用 “伪装 成 其 他 用 户 的 方式 访问 Hadoop。 以 Oozie 为 例 ， 其 安全 
访问 Hadoop 流 程 如 图 11-4 所 示 。 超 级 用 户 o0zie 向 Oozie 提 交 作业 ， 并 要 求 伪 装 成 普通 用 户 dong 在 Hadoop 上 运行 ， 而 Oozie 则 进一步 
直接 以 超级 用 户 oozie 的 身份 将 作业 提交 到 Hadoop 上 ， 并 要 求 以 用 户 dong 的 身份 运行 作业 但 使 用 oozie 的 Kerberos 赁 证 进行 身份 认 
























































证 。 








oozie(dong ) 


Application 





图 11-4 Oozie 认 证 过 程 
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本 章 概 括 了 | 














实现 方案 。 





版 本 《〈1.0 之 前 版 本 ) 中 Hadoop 存 在 的 安全 问题 ， 以 及 x 
































十 安全 的 需求 ， 并 介绍 了 Hadoop 1.0 中 新 加 入 的 安全 机 制 














AU AAS 


Hadoop 1. 0 加 入 了 Kerberos 与 令 牌 相 结合 的 身份 认证 和 基于 ACL (Access ControlList) 的 服务 访问 控制 机 制 。 客 户 端 第 一 次 访 


问 服务 器 端 时 需 进 行 Kerberos 身 份 认 证 ， 待 通过 认证 后 ， 服 务 器 端 会 为 之 生成 一 个 令 牌 ， 之 后 客户 端 只 需 凭 借 令 牌 便 可 以 访问 该 











Sl 














服务 器 端 ; Ti ACLA:Hadoop t HH AHL, FEED Ay A Hadoop'# Hy 
以 访问 对 应 的 服务 。 
























































E 何 服务 配置 允许 访问 的 用 户 列表 ， 以 决定 

















Hadoop 安 全 机 制 是 Hadoop 1.0 中 最 重要 的 功能 之 一 。 它 的 引入 标志 着 Hadoop 己 经 真正 成 熟 了 。 
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第 12 章 ”下 一 代 MapReduce 框 架 














本 书 前 面 的 章节 主要 介绍 了 第 一 代 MapReduce 框 架 (MapReduce Version 1.0, MRv1) 。 随 着 时 间 的 变迁 ，MRv 1 已 经 变 得 日 
趋 完善 和 稳定 ， 且 已 被 越 来 越 多 的 公司 采用 。 然 而 ， 随 着 数据 量 的 高 速 增长 和 新 型 应 用 的 出 现 ，MRv 1 在 扩展 性 、 可 靠 性 、 资 源 
利用 率 和 多 框架 支持 等 方面 暴露 出 了 明显 不 足 ， 由 此 诞生 了 下 一 代 MapReduce 框 架 〈MapReduce Version 2.0，MRv2) 。 









































































































































本 章 将 从 基本 设计 思想 、 实 现 细节 和 工作 流程 等 方面 对 常见 的 MRv 2 框架 的 开源 实现 进行 介绍 。 

















12.1 第 一 代 MapReduce 框 架 的 局 限 性 








MRv 1 存在 各 种 问题 ， 主 要 可 概括 为 以 下 几 个 方面 。 









































口 扩展 性 差 : 在 MRv 1 中 ，JobTracker 同 时 具备 了 资源 管理 和 作业 控制 两 个 功能 ， 这 成 为 系统 的 一 个 最 大 瓶颈 ， 严 习 
Hadoop 集 群 扩展 性 。 
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口 可 靠 性 差 : MRv 1 采用 了 masterslave 结 构 ， 其 中 ，master 存 在 单 点 故障 问题 ， 一 旦 它 出 现 故障 ， 将 导致 整个 集群 不 可 用 。 



















































































口 资源 利用 率 低 : MRv 1 采用 了 基于 槽 位 的 资源 分 配 模型 。 模 位 是 一 种 粗 粒度 的 资源 划分 单位 ， 通 常 一 个 任务 不 会 用 完 模 位 
对 应 的 资源 ， 且 其 他 任务 也 无 法 使 用 这 些 空闲 资源 。 此 外 ，Hadoop 将 槽 位 分 为 Map slot 和 Reduce slot 两 种 ， 且 不 允许 它们 之 间 共 
享 ， 这 常常 会 导致 一 种 柳 位 资源 紧张 而 男 外 一 种 闲置 的 情况 出 现 〈( 比 如 一 个 作业 刚刚 提交 时 ， 只 会 运行 Map Task， 此 时 Reduce 
sloth Æ) . 
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口 无 法 支持 多 种 计算 框架 : 随 着 互联 网 的 高 速 发 展 ，MapReduce 这 种 基于 磁盘 的 离线 计算 框架 已 经 不 能 满足 应 用 要 求 ， 从 而 
出 现 了 一 些 新 的 计算 框架 ， 包 括 内 存 计算 框架 、 流 式 计 算 框架 和 迭代 式 计算 框 架 等 ， 而 MRv 1 不 能 支持 多 种 计算 框架 并 存 。 




































































为 了 克服 以 上 几 个 缺点 ，Apache 和 Facebook 均 开始 党 试 对 Hadoop 进 行 升 级 改造 ， 进 而 诞生 了 更 加 先进 的 下 一 代 MapReduce 计 
算 框架 。 








12.2 ”下 一 代 MapReduce 框 架 概述 


12.2.1 基本 设计 思想 


[NA 


在 第 6 章 中 ， 我 们 已 经 介绍 了 JobTracker 的 基本 功能 由 TaskScheduler 模 块 实现 ) 和 作业 控制 〈 由 JobTirackerq 
多 个 模块 共同 实现 ) 两 部 分 ， 具 体 如 图 12-1 所 示 。 当 前 Hadoop MapReduce 之 所 以 在 可 扩展 性 、 资 源 利用 率 和 多 框架 支持 等 方面 存 
在 不 足 ， 正 是 由 于 Hadoop 对 JobTracker 距 予 的 功能 过 多 而 造成 负载 过 重 。 此 外 ， 从 设计 角度 上 看 ，Hadoop 未 能 够 将 资源 管理 
的 功能 与 应 用 程序 相关 的 功能 分 开 ， 造 成 Hadoop 难 以 支持 多 种 计算 框架 。 


， 包 括 资源 管理 〈 
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相关 





TaskTracker 


第 一 代 MapReduce 框 架 基 本 架构 





图 12-1 


下 一 代 MapReduce 框 架 的 基本 设计 思想 是 将 JobTracker 的 两 个 主要 功能 ， 即 资源 管理 和 作业 控制 (包括 作业 监控 、 容 错 
等 ) ， 分 拆 成 两 个 独立 的 进程 ， 如 图 12-2 所 示 。 资 源 管理 进程 是 与 具体 应 用 程序 无 关 的 模块 ， 它 负责 整个 集群 的 资源 (内 存 、 
CPU. HAS 管理 ， 而 作业 控制 进程 则 是 直接 与 应 用 程序 相关 的 模块 ， 且 每 个 作业 控 人 


空 制 进程 只 负责 管理 一 个 作业 。 这 样 ， 通 过 
将 原 有 JobTracker 中 与 应 用 程序 相关 和 无 关 的 模块 分 


， 不 仅 减轻 了 JobTracker 负 载 ， 也 使 得 Hadoop 支 持 更 多 的 计算 框架 
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图 12-2 下 一 代 MapReduce 框 架 基本 架构 








从 另外 一 个 角度 看 ， 下 一 代 MapReduce 框 架 实际 上 是 一 个 资源 统一 管理 平台 ， 它 已经 不 再 局 限于 仪 支 持 MapReduce 一 种 计算 
模型 ， 而 是 可 无 限 融 入 多 种 计算 框架 ， 且 对 这 些 框架 进行 统一 管理 和 调度 。 




















12.2.2 ”资源 统一 管理 平台 






































随 着 互联 网 的 高 速 发 展 ， 基 于 数据 密集 型 应 用 的 计算 框架 不 断 出 现 。 从 支持 离线 处 理 的 MapReduce， 到 支持 在 线 处 理 的 Storm， 从 迭代 
式 计 算 框架 Spark 到 流 式 处 理 框 架 S4..…. 各 种 框架 诞生 于 不 同 的 公司 或 者 实验 室 。 它 们 各 有 所 长 ， 各 自 解 决 了 某 一 类 应 用 问题 。 而 在 大 部 分 
互联 网 公司 中 ， 这 几 种 框架 可 能 同时 被 采用 。 比 如 在 搜索 引擎 公司 中 ， 一 种 可 能 的 技术 方案 如 下 : 网 页 建 索 引 采用 MapReduce 框 架 ， 自 然 
语言 处 理 / 数 据 挖掘 采用 Spark《〈 如 网 页 PageRank 计 算 、 聚 类 分 类 算法 等 ) ， 对 性 能 要 求 很 高 的 数据 挖掘 算法 用 MPI 等 。 考 虑 到 资源 利用 率 、 
运 维 成 本 、 数 据 共享 等 因素 ， 公 司 一 般 希 望 将 所 有 这 些 框架 部 署 到 一 个 公共 的 集群 中 ， 让 它们 共享 集群 的 资源 ， 并 对 资源 进行 统一 使 用 ， 





































































































































































































这 样 ， 便 诞生 了 资源 统一 管理 与 调度 平台 ， 如 图 12-3 所 示 。 资 源 统一 管理 与 调度 平台 的 典型 代表 是 Apache 的 YARN (Yet Another Resource 














Negotiator) 、Facebook 的 Corona 和 Berkeley 的 Mesos。 


Hadoop Spark MPI 
~ | ~| | 加 D B ~ 
Hadoop Spark 


YARN /Corona/ Mesos 
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图 12-3 资源 统一 管理 与 调度 平台 的 基本 架构 


























从 上 面 分 析 可 知 ，MRv 2 实际 上 是 一 个 资源 统一 管理 平台 。 它 的 目标 已 经 不 再 局 限于 支持 MapReduce 一 种 计算 框架 ， 而 是 朝 着 对 多 种 杠 





架 进行 统一 管理 的 方向 发 展 。 








相 比 于 “一 种 计算 框架 一 个 集群 ?的 模式 ， 共 享 集群 的 模式 存在 多 种 好 处 。 
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口 资 源 利 用 率 高 : 如 图 12-4 所 示 ， 如 果 每 个 框架 一 个 集群 ， 则 往往 由 于 应 用 程序 数量 和 资源 需求 的 不 均衡 性 ， 使 得 在 某 段 时 间 内 ， 有 



























































些 计 算 框 架 的 集群 资源 紧张 ， 而 男 外 一 些 集群 资源 空间 。 共 享 集群 模式 则 通过 多 种 框架 共享 资源 ， 使 得 集群 中 的 资源 得 到 更 加 充分 的 利 








用 。 
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Shared cluster 


图 12-4 共享 集群 模式 使 得 资源 利用 率 提 高 











口 运 维 成 本 低 : 如 果 采 用 “一 个 框架 一 个 集群 "的 模式 ， 则 可 能 需要 多 个 管理 员 管理 这 些 集群 ， 进 而 增加 运 维 成 本 ， 而 共享 模式 通常 需 
要 少数 管理 员 即 可 完成 多 个 框架 的 统一 管理 。 


口 数 据 




















享 : 随 着 数据 量 的 暴 增 ， 跨 集群 间 的 数据 移动 不 仅 需 花费 更 长 的 时 间 ， 且 硬件 成 本 也 会 大 大 增加 ， 而 共享 集群 模式 可 让 多 种 








框架 共享 数据 和 硬件 资源 ， 将 大 大 减少 数据 移动 带 来 的 成 本 。 


12.3 Apache YARN 


YARN 是 Apache 的 下 一 代 MapReduce 
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E 架 。 它 的 基本 设计 思想 
ResourceManager 和 每 个 应 用 程序 特有 的 ApplicationMaster。] 
责 单 个 应 用 程序 的 管理 。 
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是 将 JobTracker 拆 分 成 两 个 独立 的 服务 : 一 个 








全 局 的 资源 管理 器 
其 中 ，ResourceManager 负 责 整个 系统 的 资源 管 


pr JH 


Apache YARN 基 本 框架 











和 分 配 ， 而 ApplicationMaster 则 负 


YARN 总 体 上 仍然 是 masterslave 结 构 。 在 整个 资源 管理 
个 NodeManager 上 的 资源 进行 统一 管理 和 调度 。 











当 用 户 提交 一 个 
负责 向 ResourceManager 申 请 资源 ， 并 要 求 NodeManager 启 动 可 以 
此 它们 之 间 不 会 相互 














框架 中 ，ResourceManager 为 master, NodeManager 为 sjave, ResourceManager 负 责 对 各 
应 用 程序 时 ， 需 要 
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是 供 一 个 用 
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定 资源 的 但 


于 跟踪 和 管理 
本 组 成 结构 和 RPC 框 架 两 方 1 









































这 个 程序 的 ApplicationMaster。 它 
于 不 同 的 ApplicationMaster 分 布 厂 


E 不 同 的 节点 上 ， 
对 YARN 进 行 介 绍 。 
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12-5 描 述 了 YARN 的 基本 组 成 结构 。YARN 主 要 由 ResourceManager、NodeManager、ApplicationMaster (图 中 给 出 了 MapReduce 和 MPI 两 
种 计算 框架 的 ApplicationMaster， 分 别 为 MR AppMstr 和 MPI AppMstr) 和 Container 等 几 个 组 件 构成 。 








(1) ResourceManager (RM) 


12-5 Apache YARN 的 基本 架构 
RM 是 一 个 全 局 的 资源 管 
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(Applications Manager, ASM) 。 





器 ， 负 责 整 个 系统 的 资源 管理 和 分 配 。 它 主要 
调度 器 




















两 个 组 件 构成 : 调度 器 〈Scheduler) 和 应 月 
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调度 器 根据 容量 、 队 列 等 限制 条 件 〈 如 每 个 队列 分 配 一 定 的 资源 ， 最 多 执行 一 定数 量 的 作业 等 ) ， 将 系统 





FP 的 资源 分 配给 各 个 症 
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行 的 应 用 程序 。 需 要 注意 的 是 ， 该 调度 器 是 一 个 “ 纯 调 度 器 ”， 它 从 事 任 何 与 具体 应 用 程序 相关 的 工作 ， 比 如 不 负责 监控 或 者 跟踪 应 用 的 执 
行 状 态 等 ， 也 不 负责 重新 启动 因应 用 执行 失败 或 者 硬件 故障 而 产生 的 失败 任务 ， 这 些 均 交 由 应 用 程序 相关 的 ApplicationMaster 完 成 。 调 度 器 
仅 根 据 各 个 应 用 的 资源 需求 进行 资源 分 配 ， 而 资源 分 配 单位 用 一 个 抽象 概念 “资源 容器 ”(Resource Container， 简 称 Container) 表示 。Container 
是 一 个 动态 资源 分 配 单位 ， 它 将 内 存 、CPU、 磁 盘 、 网 络 等 资源 封装 在 一 起 ， 从 而 限定 每 个 任务 使 用 的 资源 量 。 此 外 ， 该 调度 器 是 一 个 可 


插 拔 的 组 件 ， 用 户 可 根据 自己 的 需要 设计 新 的 调度 器 ，YARN 提 供 了 多 种 直接 可 用 的 调度 器 ， 比 如 Fair Scheduler 和 Capacity Scheduler 等 。 
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应 用 程序 管理 器 









































应 用 程序 管理 器 负责 管理 整个 系统 中 所 有 应 用 程序 ， 包 括 应 用 程序 提交 、 与 调度 器 协商 资源 以 启动 ApplicationMaster、 监 控 
ApplicationMaster 运 行 状态 并 在 失败 时 重新 启动 它 等 。 





















































为 了 保证 高 可 用 性 ，ResourceManager 将 所 有 状态 信息 保存 到 了 Zookeeper 吊 中， 它 可 以 通过 保存 在 Zookeeper 中 的 状态 快速 重 
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(2) ApplicationMaster (AM) 























fann 





户 提交 的 每 个 应 用 程序 均 包 含 一 个 AM。 它 实际 上 是 一 个 简化 版 的 JobTracker， 主 要 功能 包括 : 











口 与 RM 调度 器 协商 以 获取 资源 。 

















口 与 NM 通信 以 启动 /停止 任务 。 









































口 监控 所 有 任务 的 运行 状态 ， 并 在 任务 运行 失败 时 重新 为 任务 申请 资源 以 重启 任务 。 
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当前 YARN 自 带 了 两 个 AM 实现 : 一 个 是 用 于 演示 AM 编写 方法 的 实例 程序 distributedshel， 它 可 以 申请 一 定数 目的 Container 运 行 一 个 shel 
命令 或 者 shel 脚 本 ;， 另 一 个 是 运行 MapReduce 应 用 程序 的 AM 一 MRAppMaster， 我 们 将 在 12.3.4 节 对 其 进行 介绍 。 此 外 ， 一 些 其 他 的 计算 村 
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架 对 应 的 AM 正在 开发 中 ， 比 如 Open MPI. Spark“# lP, 





(3) NodeManager (NM) 








NM 是 每 个 节点 上 的 资源 和 任务 管理 器 。 一 方面 ， 它 会 定时 地 向 RM 汇报 本 节点 上 的 资源 使 用 情况 和 各 个 Container 的 运行 状态 ， 另 一 方 
面 ， 它 接收 并 处 理 来 自 AM 的 任务 启动 /停止 等 各 种 请 求 。 






































(4) Container 














Container 是 YARN 中 的 资源 分 配 单位 ， 它 封装 了 多 维度 的 资源 ， 如 内 存 、CPU、 和 磁盘 、 网 络 等 。 当 AM 向 RM 申请 资源 时 ，RM 为 AM 返回 
的 资源 便 是 用 Container 表 示 的 。YARN 中 每 个 任务 均 会 对 应 一 个 Container， 且 该 任务 只 能 在 该 Container 中 执行 ， 并 仅 能 使 用 该 容器 代表 的 资 
源 量 。 需 要 注意 的 是 ，Container 不 同 于 MRv 1 中 的 slot， 它 是 一 个 动态 资源 划分 单位 ， 是 根据 应 用 程序 的 需求 动态 生成 的 。 截 至 完成 此 书 


时 ，YARN 仅 支持 CPU 和 内 存 两 种 资源 ， 且 使 用 了 Linux Container 进 行 资源 隔离 Pl. 







































































































































































2.YARN 的 RPC 协 议 与 序列 化 框架 




















RPC 协 议 是 连接 各 个 组 件 的 “大 动脉 ” 了 解 不 同 组 件 之 间 的 RPC 协 议 有 助 于 我 们 更 深入 地 学 习 YARN 框 架 。 在 YARN 中 ， 任 何 两 个 需 相 
互通 信 的 组 件 之 间 仅 个 RPC 协 议 ， 而 对 于 任何 一 个 RPC 协 议 ， 通 信 双 方 有 一 端 是 Client， 男 一 端 为 Server， 且 Client 总 是 主动 连接 Server， 
因此 ，YARN 实 际 上 采用 的 是 拉 式 (pulLbased) 通信 模型 。 如 图 12-6 所 示 ，YARN 主 要 由 以 下 几 个 RPC 协 议 组 成 。 
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图 12-6 Apache YARN 的 RPC 协 议 














名 单 、 用 户 队列 权限 等 。 











证 








口 NM 与 RM 之 间 的 协议 一 一 ResourceTracker:， NM 通过 该 RPC 协 议 向 RM 注册 ， 


Container 运 行情 况 。 









































为 了 提高 Hadoop 的 向 后 兼容 性 和 不 同 版 本 之 间 的 兼容 性 ，YARN 中 的 序列 化 框 























引入 使 得 YARN (与 MRv 1 相 比 ) 在 兼容 性 方面 向 前 迈进 了 一 大 步 。 























[1] PttpVzookeeper. apache.org/ 
[2] http/wiki. apache.org/hadoop/PoweredByYarn 
[3] httpsVissues. apache.org/jira/browse/YARN-3 











NodeManager 


O Administrator CEHA) 与 RM 之 间 的 通信 协议 一 一 RMAdminProtocol;， Administrator 通 过 该 RPC 协 议 更 新 系统 配置 文件 ， 比 如 节点 黑白 






(NM) 





O Job Client (ENEZ AA m) 与 RM 之 间 的 协议 一 一 ClientRMProtocol: Clent 通 过 该 RPC 协 议 提交 应 用 程序 ， 查 询 应 用 程序 状态 等 。 
























































口 AM 与 RM 之 间 的 协议 一 一 AMRMProtocol: Job AM 通过 该 RPC 协 议 向 RM 注册 和 撤销 自己 ， 并 为 各 个 任务 申请 资源 。 

















口 AM 与 NM 之 间 的 协议 一 一 ContainerManager: AM 通过 该 RPC 协 议 要 求 NM 启 动 或 者 停止 Container， 获 取 各 个 Container 的 使 用 状态 等 信 






































并 定时 发 送 心跳 信息 汇报 当前 节点 的 资源 使 用 情况 和 

















采用 了 Goosle 开 源 的 Protocol Buffers. Protocol Buffers 的 


12.3.2 Apache YARN 工 作 流 程 











当 用 户 向 YARN 中 提交 一 个 应 

























































































程序 后 ，YARN 将 分 两 个 阶段 运行 该 应 用 程序 : 





第 二 个 


第 一 个 阶段 是 启动 ApplicationMaster; 






































































































































































































































































































































































































































































































































阶段 是 由 ApplicationMaster 创 建 应 用 程序 ， 为 它 申请 资源 ， 并 监控 它 的 整个 运行 过 程 ， 直 到 运行 成 功 。 如 图 12-7 所 示 ，YARN 的 工 
作 流 程 分 为 以 下 几 个 步 又 : 

步骤 1 用 户 向 YARN 中 提交 应 用 程序 ， 其 中 包括 ApplicationMaster 程 序 、 启 动 ApplicationMaster 的 命令 、 用 户 程 序 等 。 

步 又 2 ” ResourceManager 为 该 应 用 程序 分 配 第 一 个 Container， 并 与 对 应 的 NodeManager 通 信 ， 要 求 它 在 这 个 Container 中 启动 应 
程序 的 ApplicationMaster。 

步 又 3 ApplicationMaster 首 先 向 ResourceManager 注 册 ， 这 样 ， 用 户 可 以 直接 通过 ResourceManager 查 看 应 用 程序 的 运行 状态 ; 
然后 ， 它 将 为 各 个 任务 申请 资源 ， 并 监控 其 运行 状态 ， 直 到 运行 结束 ， 即 重复 步骤 4 一 7。 

步骤 4 ”ApplicationMaster 采 用 轮 询 的 方式 ， 通 过 RPC 协 议 向 ResourceManager 申 请 和 领取 资源 。 

步骤 5 ”一旦 ApplicationMaster 申 请 到 资源 后 ， 就 与 对 应 的 NodeManager 通 信 ， 要 求 其 启动 任务 。 

步骤 6 NodeManager 为 任务 设置 好 运行 环境 (包括 环境 变量 、jar 包 、 二 进 制程 序 等 ) 后 ， 将 任务 启动 命令 写 到 一 个 脚本 
中 ， 并 通过 运行 该 脚本 启动 任务 。 

步骤 7 各 个 任务 通过 某 个 RPC 协 议 向 ApplicationMaster 汇 报 自己 的 状态 和 进度 ， 以 让 ApplicationMaster 随 时 掌握 各 个 任务 的 运 
行 状 态 ， 从 而 可 以 在 任务 失败 时 重新 启动 任务 。 

在 应 用 程序 运行 的 过 程 中 ， 用 户 可 随时 通过 RPC 协 议 向 ApplicationMaster 查 询 应 用 程序 的 当前 运行 状态 

步骤 8 ”应 用 程序 运行 完成 后 ，ApplicationMaster| 句 ResourceManager 注 销 ， 并 关闭 自己 。 
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图 12-7 Apache YARN 的 工作 流程 


12.3.3 Apache YARN 设 计 细节 


Apache YARN 在 系统 架构 和 软 伯 





F 设 计 等 方面 和 MRv 1 相 比 都 有 






































明显 的 改进 。 在 前 几 节 中 ， 我 们 已 经 介绍 了 它 的 全 新 系统 架构 ， 而 在 




































































































































































本 小 节 中 ， 我 们 重点 从 软件 设计 和 资源 调度 模型 两 方面 介绍 其 采用 的 关键 技术 : 在 软件 设计 方面 ，YARN 采 用 了 基于 服务 的 对 象 管 理 模 
型 和 基于 事件 驱动 的 并 发 模型 ， 而 在 资源 调度 模型 方面 ，YARN 采 用 了 更 为 细 粒 度 的 基于 真实 资源 需求 量 的 调度 模型 。 

1. 基 于 服务 的 对 象 管理 模型 

对 于 生命 周期 较 长 的 对 象 ，YARN 采 用 了 基于 服务 的 对 象 管 理 模型 对 其 进行 管理 。 该 模型 主要 有 以 下 几 个 特点 。 

口 将 每 个 被 服务 化 的 对 象 分 为 4 个 状态 : NOTINITED 被 创建 )、INITED (已 初始 化 ) ~ STARTED (已 启动 ) 、STOPPED (已 停 

















止 ) 。 


口 任何 服务 状态 变化 都 可 以 触发 另外 一 些 动作 。 



































口 可 通过 组 合 的 方式 对 任意 服务 进行 组 合 ， 以 便 进 行 统 一 管理 。 
YARN 中 关于 服务 模型 的 类 图 如 图 12-8 所 示 。 在 这 个 图 中 ， 我 们 可 以 看 到 ， 所 有 的 服务 对 象 最 终 均 实现 了 接口 














本 的 服务 初始 化 、 局 动 、 停 止 等 操作 ， 而 AbstractService 类 则 提供 了 一 个 最 基本 的 Service 实 现 。YARN 中 所 有 对 象 ， 





Service， 它 定义 了 最 基 
如 果 是 非 组 合 服务 ， 








则 直接 继承 AbstractService 类 即 可 ， 否 则 需 继 承 CompositeService。 比 如 ， 对 于 ResourceManager 而 言 ， 它 是 一 个 组 合 月 


务 对 象 ， 包 括 ClentRMService、ApplicationMasterLauncher、ApplicationMasterLauncher 等 。 








<<interface>> 
Service 
tinit (in config : Configuration ) 
+start () 


tstop() 
tregister (in listener : ServiceStateChangeListener) 
+unregister (in listener : ServiceStateChangeListener) 














AbstractService 
-listeners : List<ServiceStateChangeL istener> 
-state : STATE 
人 





ApplicationMaster Launcher 


D> 

































12-8 ” ”YARN 中 服务 模型 的 类 图 
2. 基 于 事件 驱动 的 并 发 模型 
YARN 采 用 了 基于 事件 驱动 的 并 发 模型 。 该 模型 能 够 大 大 增强 并 发 性 ， 从 而 提高 系统 整体 改 




















务 ， 它 组 合 了 各 种 服 


已 
区 





能 。 为 了 构建 该 模型 ，YARN 将 各 种 处 理 





in! 





















































逻辑 抽象 成 事件 和 对 应 事件 调度 器 ， 并 将 每 类 事件 的 处 理 过 程 分 割 成 多 个 步骤 ， 用 有 限 状 态 机 表示 。YARN 中 的 事件 处 理 模型 如 图 12-9 
所 示 。 


Event Type] event 
Event Type2 uma event Event Handler 


Event Type3 











Event Queue 
Event Handler 





event2 
Event Rao | 


event] event3 


图 12-9 YARN 的 事件 处 理 模型 












































整个 处 理 过 程 大 致 为 :处理 请 求 会 作为 事件 进入 系统 ， 由 中 央 调 度 器 〈AsyncDispatcher) 负责 传递 给 相应 事件 调度 器 (Event 
Handler) ， 该 事件 调度 器 可 能 将 该 事件 转发 给 另外 一 个 事件 调度 器 ， 也 可 能 交 给 一 个 带 有 有 限 状 态 机 的 事件 处 理 器 ， 其 处 理 结果 也 以 事 
件 的 形式 输出 给 中 央 调 度 器 ， 而 新 的 事件 会 再 次 被 中 央 调 度 器 转发 给 下 一 个 事件 调度 器 ， 直 至 处 理 完成 〈 达 到 终止 条 件 ) 。 























































































































3. 基 于 真实 资源 需求 量 的 调度 模型 
































不 同 于 MRv 1 中 基于 slot 的 资源 模型 ，YARN 采 用 了 基于 真实 资源 需求 量 的 调度 模型 : 集群 中 各 个 节点 周期 性 向 ResourceManager 汇 报 

































































各 类 资源 使 用 情况 〈 如 CPU、 内 存 等 ) ， 而 ResourceManager 则 根据 各 个 作业 的 真实 资源 量 需求 ， 结 合 一 些 资源 约束 ， 进 行 资源 分 配 和 任 
务 调度 。 


















































用 户 提交 应 用 程序 后 ， 对 应 的 ApplicationMaster 负 责 将 应 用 程序 的 资源 需求 转化 成 符合 特定 格式 的 资源 请 求 ， 并 发 送 给 
ResourceManager。 一 旦 某 个 节点 出 现 空闲 资源 ，ResourceManager 中 的 调度 器 将 决定 把 这 些 空 闲 资源 分 配给 哪个 应 用 程序 ， 并 封装 成 
Container 返 回 给 对 应 的 ApplicationMaster。 









































ApplicationMaster 发 送 的 资源 请 求 形式 如 下 : 





<Priority, Hostname, Resource, #Container> 




















上 述 的 形式 中 涉及 的 几 个 属性 的 含义 分 别 如 下 。 























口 Priority: 资源 优先 级 。 不 同 于 MRv 1 中 的 优先 级 概念 (只 有 5 种 优先 级 ， 且 难以 扩展 ) ，YARN 人 允许 优先 级 是 任意 正 整 数 ， 而 具体 
怎样 规划 各 种 资源 的 紧急 程度 ， 完 全 由 应 用 程序 的 ApplicationMaster 决 定 。 比 如 YARN 自 带 的 MapReduce 框 架 的 ApplicationMaster 将 资源 分 为 









































三 种 优先 级 ， 分 别 是 PRIORITY_FAST FAIL MAP (运行 失败 Map Task Attempt 所 需 资 源 的 优先 级 ) 、PRIORITY REDUCE (Reduce Task 
所 需 资源 的 优先 级 ) 和 PRIORITY MAP (Map Task 所 需 资源 的 优先 级 ) ， 优 先 级 分 别 是 S、10 和 20 (Priority 对 应 的 数值 越 小 ， 优 先 级 越 
高 ) 。ResourceManager 将 优先 为 优先 级 高 的 任务 分 配 资源 。 

















口 Hostname: 期 望 分 配 的 资源 所 在 节点 。 调 度 器 会 优先 为 应 用 程序 分 配 满足 数据 本 地 化 的 资源 ， 这 样 可 避免 移动 数据 从 而 提高 效 
率 。 而 根据 数据 本 地 化 的 三 个 级 别 〈Node-local、Rack-local 和 O 企 switch) ， 该 属性 有 三 个 可 选 值 ， 资 源 所 在 节点 ， 资 源 所 在 机 架 和 '*”。 


























“表示 可 在 任何 节点 上 。 
2.0.3-alpha 版 本 ，YARN 仅 支持 CPU 和 内 存 两 种 资源 。 











中 ， 





量 。 对 于 MapReduce 而 言 ， 同 





N 
个 





do WA 




















MAJER) 的 Container 的 数 








口 Resource: 表示 需要 的 资源 
口 #Container: 需要 符合 以 上 资源 描述 (优先 级 、 所 在 节点 和 资源 需求 三 方 
一 个 作业 的 所 有 同类 型 任务 需要 的 资源 量 是 相同 的 。 
【实例 】“<10，nodeX, memory: 2GBICPU: 1，2> ”表示 请 求 2 个 满足 以 下 条 件 的 优先 级 为 10 的 Container: 
级 均 为 10。 这 意味 着 ， 如 果 没 有 优先 级 更 高 的 Container 需 求 ， 则 需要 优先 分 配 这 2 个 Container。 





位 于 节点 nodeXF、2 GB 















































§ Container’) fi, 
Ph 每 个 Container 主 要 包含 以 下 内 容 : 











Et 
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A~ 14SCPU, ixp 
如 果 ApplicationMaster 获 取 到 了 新 资源 ， 它 会 收 到 一 个 Container 列 表 ， 











全 认 











































































































<ContainerId, NodeId, NodeHttpAddress, Resource, ContainerToken> 
当 收 到 一 个 有 D 为 ContainerId 的 Container 后 ，ApplicationMaster 将 与 人 D 为 Nodeld 的 NodeManager 通 信 ， 并 使 用 ContainerToken 进 行 安 4 
证 ， 以 要 求 它 启动 一 个 占用 Resource 资 源 量 的 Container， 在 该 Container 中 启动 任务 。 与 MRv 1 只 能 够 启动 Java 应 用 程序 不 同 ，YARN 人 允许 启 
动 任意 进程 ， 比 如 Shel 脚 本 、PHP 进 程 、Python 进 程 等 。 





[1] httpsVissues. apache.org/jira/browse/YARN-2 


12.3.4 MapReduce 与 YARN 结 合 

















如 果 用 户 想 要 让 一 个 新 的 计算 相 
应 用 程序 的 一 部 分 被 提交 到 YARNT 
务 的 形式 部 署 到 各 个 节点 上 。 




















医 架 运行 在 YARN 上 ， 需 





将 该 框架 重新 封装 成 一 个 ApplicationMaster， 而 ApplicationMaster 将 作为 用 户 





FP。 换 句 话说 ，YARNT 



































Ph 的 所 有 计算 框架 实际 上 只 是 客户 端的 一 个 库 ， 因 此 ， 不 必 单 独 将 这 个 框架 以 服 


























于 YARN 是 直接 从 MRv 1 衍化 过 来 也 

















MRAppMaster。 接 下 来 我 们 将 详细 对 其 进 
1.MRAppMaster: 


为 了 能 够 让 MapReduce 高 效 
效 。YARN 对 MRy 1 的 修改 3 


口 将 JobTracker 中 的 作业 控 和 
ApplicationMaster—MRAppMaster. 


口 TaskTracker 的 部 分 功能 1 











口 利 用 状态 机 




















口 利用 状态 机 
新 的 MapReduce 计 算术 


口 ContainerAllocator: ContainerAllocator 负 责 将 Map Task 和 Reduce Task 需 要 的 资源 转化 成 ResourceManager 可 识别 的 表示 
AMRMProtocol 协 议 向 Resource-Manager 申 请 资 
























































在 YARN 之 上 ，YARN 采 用 异步 事件 模型 对 MRv 1 中 的 几 个 导 












































模块 TaskAttemptListenerImp] 完 成 。 


























Loo 


EE 写 JobInProgress 类 ， 



































EE 写 TaskInProgress 类 ， 







































































支持 MapReduce 计 算 框架 。MapReduce 框 架 对 应 的 ApplicationMaster 为 



































pan 
xe 





数据 结构 进行 ] 


[fail 
mEn 








写 ， 使 其 更 加 高 


作业 运行 状态 等 ) 部 分 拆 分 出 来 ， 按 照 规范 实现 MapReduce 计 算 框架 的 


JobImp] 完 成 。 


















































MapTaskImplJReduceTaskImp] 完 成 。 
都 浓缩 在 了 MRAppMaster 中 ， 其 主要 架构 如 图 12-10 所 示 。 它 主要 由 以 下 几 个 模块 组 成 。 
BS 式 ， 并 通过 
































口 ContainerLauncher: MRAppMaster 从 ResourceManager 端 获取 的 资源 是 以 Container 表 示 的 。Container 中 包含 资源 所 在 节点 、 资 源 种 类 以 


及 每 种 资源 的 可 用 量 等 


口 TaskAttemptListener: 
现 了 TaskUmbilicalProtocol 协 议 ， 所 有 任务 周 其 


算 。 


DQ JobTokenSecretManager: 


考 第 10 章 。 





口 Task Cleaner: Task Cleaner 负 责 清 理 失败 或 者 被 
口 Speculator: 如 果 发 现 某 个 人 


口 Recovery Service: ~4ApplicationMaster 


新 计算 这 些 任务 。 


QMRClientService: MRClientService 负 责 与 客户 端 交 互 ， 可 为 客户 端 提供 作业 当前 执行 状态 、 进 度 等 信息 。 





























息 。ContainerLauncher 通 过 ContainerManager 协 议 与 对 应 的 节点 通信 ， 要 求 它 启动 任务 。 













































































HAYTaskTracker; 不同 的 是 ， 它 不 是 管理 某 个 节点 上 的 任务 ， 而 是 所 有 节点 上 的 任务 。 它 实 
[ 报 运行 状态 。 如 果 某 个 任务 在 一 段 时 间 内 未 发 送 心 跳 信息 ， 它 会 将 其 杀 死 以 重新 计 















































里 作业 令 牌 。 作 业 令 牌 是 Task 与 MRAppMaster 通 信 ，Reduce Task 从 Map Task 找 贝 数据 的 赁 证， 具体 可 参 












































死 任务 产生 的 不 完整 输出 结果 ， 以 防止 大 量 无 用 的 任务 产生 的 结果 塞 满 磁 盘 。 
































的 执行 速度 落后 了 









































启动 后 ，Recovery Service 可 从 日 志 中 重 构 已 经 运行 完成 的 任务 的 信息 ， 进 而 避免 习 








其 他 任务 ， 则 Speculator 会 为 该 任务 启动 一 个 备份 任务 ， 有 具体 参考 第 6 章 。 
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图 12-10 ”MRAppMaster 的 内 部 结构 


2.MRAppMaster 工 作 流 程 




















按照 作业 大 小 不 同 ，MRAppMaster 提 供 了 三 种 作业 运行 模式 : 本 地 模式 〈 通 常用 于 作业 调试 ， 与 MRv 1 一 样 ， 不 再 费 述 ) 、Uber 模 式 


























中 和 NonUber 模 式 。 对 于 小 作业 ， 为 了 降低 其 延迟 ， 可 采用 Uber 模 式 。 在 该 模式 下 ， 所 有 Map Task 和 Reduce Task 在 同一 个 
Container (MRAppMaster 所 在 Container) 中 顺 次 执行 。 对 于 大 作业 ， 则 采用 NomUber 模 式 。 在 该 模式 下 ，MRAppMaster 先 为 Map Task 申 请 
资源 ， 当 Map Task 运 行 完成 的 数目 达到 一 定 比 例 后 再 为 Reduce Task 申 请 资源 。 










































































(1) Uber 运 行 模式 


























为 了 降低 小 作业 延 时 ，YARN 专 门 对 小 作业 运行 方式 进行 了 优化 。 对 于 小 作业 而 言 ，MRAppMaster 无 须 再 为 每 个 任务 分 别 申请 资源 ， 
而 是 让 其 重用 一 个 Container， 并 按照 先 Map Task 后 Reduce Task 的 运行 方式 串 行 执行 每 个 任务 。 在 YARN 中 ， 如 果 一 个 MapReduce 作 业 同 时 
满足 以 下 条 件 ， 则 认为 是 小 作业 ， 可 运行 在 Uber 模 式 下 : 












































口 Map Task 数 目 不 超 过 mapreduce.job.ubertask.maxmaps (默认 是 9) 。 
口 Reduce Task 数 目 不 超 过 mapreduce.job.ubertask.maxmaps (默认 是 1) 。 


口 输入 文件 大 小 不 超过 mapreduce.job.ubertask.maxbytes 〈 默 认 是 一 个 Block 大 小 ) 。 























口 Map Task 和 Reduce Task 需 要 的 资源 量 不 超过 MRAppMaster 可 使 用 的 资源 量 。 














另外 ， 由 于 链 式 作 业 会 并 发 执行 Map Task 和 Reduce Task， 因 此 不 允许 运行 在 Uber 模 式 下 。 




















(2) Non-Uber 运 行 模式 
































在 大 数据 环境 下 ，Uber 运 行 模 式 通 常 只 能 覆盖 到 一 小 部 分 作业 ， 而 对 于 其 他 大 多 数 作 业 ， 仍 将 运行 在 Non-Uber 模 式 下 。 在 Non-Uber 
模式 下 ，MRAppMaster 将 一 个 作业 的 Map Task 和 Reduce Task 分 为 以 下 四 种 状态 。 

















口 pending: 刚 启 动 但 尚未 向 ResourceManager 发 送 资源 请 求 。 


Oscheduled: 已 经 向 ResourceManager 发 送 资源 请 求 但 尚未 分 配 到 资源 。 





Dassigned: 已 经 分 配 到 了 资源 且 正 在 运行 。 





口 completed: 已 经 运行 完成 。 




















k=} 


对 于 Map Task 而 言 ， 它 的 生命 周期 为 scheduled 一 assigned 一 completed; 而 对 于 Reduce Task 而 言 ， 它 的 生命 周期 为 
pending—scheduled—assigned—completed. HH Reduce Task 的 执行 依赖 于 Map Task 的 输出 结果 ， 因 此 ， 为 避免 Reduce Task 过 早 启 动 而 造成 
资源 利用 率 低下 ，MRAppMaster 让 刚 启 动 的 Reduce Task 处 于 pending 状 态 ， 以 便 能 够 根据 Map Task 运 行情 况 决 定 是 否 对 其 进行 调度 。 在 
YARN 之 上 运行 MapReduce 作 业 需 要 解决 两 个 关键 问题 : 如 何 确定 Reduce Task 启 动 时 机 以 及 如 何 完 成 Shuffle 功 能 







































































0 何 确定 Reduce Task 启 动 时 机 


pay 



























































于 YARN 中 不 再 有 Map slot 和 Reduce slot 的 概念 ， 且 RedouceManager 也 不 知道 Map Task Reduce Task 之 间 存 在 依赖 关系 ， 医 
此 ，MRAppMaster 自 己 需 设计 资源 申请 策略 以 防止 因 Reduce Task 过 早 启 动 而 造成 资源 利用 率 低 下 和 Map Task 因 分 配 不 到 资源 而 “ 饿 死 ”。 
MRAppMaster 在 MRv 1 原 有 策略 (Map Task 完 成 数目 达到 一 定 比例 后 才 允 许 启动 Reduce Task) 基础 上 添加 了 更 为 严格 的 资源 控制 策略 和 抢 
65 策略。 总结 起 来 ，Reduce Task 启 动 时 机 由 以 下 三 个 参数 控制 。 















































































































































口 mapreduce. job.reduce.slowstart.completedmaps: 当 Map Task 完 成 的 比例 达到 该 值 后 才 会 为 Reduce Task 申 请 资源 ， 默 认 是 0.05。 








口 yam. app.mapreduce.am.job.reduce.rampup.limit: 在 Map Task 完 成 前 ， 最 多 启动 的 ReduceTask 比 例 ， 默 认为 0.5。 








Qyam. app.mapreduce.amjob.reduce.preemption limit: =4Map Task 需 要 资源 但 暂时 无 法 获取 资源 (比如 Reduce Task 运 行 过 程 中 ， 部 分 Map 
Task 因 结果 丢失 需 重 算 ) 时 ， 为 了 保证 至 少 一 个 Map Task 可 以 得 到 资源 ， 最 多 可 以 抢占 的 Reduce Task 比 例 ， 默 认为 0.5。 






































如 何 完成 Shuffe 功 能 























按照 MapReduce 的 基本 逻辑 ，Shuffle HTTP Server 应 该 分 布 到 各 个 节点 上 ， 以 便 能 够 支持 各 个 Reduce Task 远 程 拷贝 数据 。 然 而 ， 由 于 
Shuffe 是 MapReduce 框 架 中 特有 的 一 个 处 理 流程 ， 从 设计 上 讲 ， 不 应 该 将 它 直 接 嵌 到 YARN 的 某 个 组 件 〈 比 如 NodeManager) 中 。 











































































































前 面 提 到 ，YARN 采 用 了 服务 模型 管理 各 个 对 象 ， 且 多 个 服务 可 以 通过 组 合 的 方式 交 由 一 个 服务 进行 统一 管理 。 在 YARN 
中 ，NodeManager 作 为 一 种 组 合 服务 模式 ， 人 允许 动 态 加载 应 用 程序 临时 需要 的 附加 服务 。 利 用 这 一 特性 ，YARN 将 Shufle HTTP Server 组 装 
成 了 一 种 服务 ， 以 便 让 各 个 NodeManager 加 载 它 。 













































































[1] https//Assues. apache.org/jira/browse/ MAPREDUCE-2405 


12.4 Facebook Corona 

















Corona!!! 是 Facebook 于 2012 年 11 月 开源 的 下 一 代 MapReduce 框 架 。 它 的 设计 目标 与 YARN 类 似 ， 在 Facebook 团 队 的 博文 站 中 如 此 描 
述 Corona 的 设计 目标 : 





















































口 更 好 的 可 扩展 性 和 集群 资源 利用 率 。 








口 更 小 的 短 作业 运行 延迟 。 


口 文 持 在 线 版 本 更 新 。 














口 基 于 真实 资源 需求 进行 任务 调度 。 
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与 YARN 最 大 的 不 同 是 ，Corona 和 暂时 未 考虑 对 多 计算 框架 的 支持 ， 也 就 是 说 ，Corona 的 目标 限定 在 MapReduce 一 种 计算 框架 中 C 
管 在 源 代码 中 将 Corona 和 MapReduce 代 码 分 开 存放 到 不 同 的 jar 包 中 ， 但 它们 还 是 耦合 在 一 起 的 ) 。 
































接 下 来 将 重点 介绍 Corona 的 基本 框架 和 工作 原理 。 




















12.4.1 Facebook Corona 基 本 框架 
































与 YARN 一 样 ，Corona 也 采用 了 masterslave 结 构 。 它 们 的 基本 思想 也 是 一 致 的 ， 即 将 JobTracker 拆 分 成 了 两 个 独立 的 服务 : 全 局 的 资 
源 管 理 器 ClusterManager 和 每 个 应 用 程序 特有 的 CoronaJobTracker。 其 中 ，ClusterManager 负 责 整个 系统 的 资源 管理 和 分 配 ， 而 
CoronaJobTracker 则 负责 单个 应 用 程序 的 管理 。 
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1.Corona 的 基本 组 成 结构 


(1) ClusterManager (CM) 











类 似 于 YARN 中 的 ResourceManager， 负 责 系统 资源 分 配 和 调度 。ClusterManager 掌 握 着 各 个 节点 的 资源 使 用 情况 ， 并 将 资源 分 配给 各 
个 应 用 程序 〈 采 用 的 调度 器 为 Fair Scheduler) 。 此 外 ， 考 虑 到 在 新 架构 中 ，ClusterManager 本 身 出 故障 的 可 能 性 非常 低 ， 它 的 高 可 用 性 通 
常 仅 用 于 在 线 升级 ， 因 此 ，Corona 在 ClusterManager 高 可 用 性 方面 设计 的 非常 简单 : 仅 支持 人 工 触 发 命令 将 ClusterManager 状 态 信息 保存 到 
一 个 镜像 文件 中 ， 并 在 升级 结束 后 将 其 从 该 文件 中 恢复 。 






































































































































(2) CoronaJobTracker (CJT) 























类 似 于 YARN 中 的 ApplicationMaster， 用 于 MapReduce 应 用 程序 的 监控 和 容错 。 在 Corona 中 ，CoronaJobTracker 可 以 运行 在 三 个 模式 
Peo 





























口 同 进程 模式 : 运行 在 客户 端 中 ， 该 模式 能 大 大 降低 小 作业 运行 延迟 。 























口 转发 模式 : 将 来 自 客户 端的 请 求 转发 给 位 于 远程 模式 下 的 CoronaJobTracker。 








口 远程 模式 : 运行 在 某 个 CoronaTaskTracker 上 ， 它 最 重要 的 任务 是 为 作业 申请 资源 和 监控 作业 的 运行 过 程 ， 直 到 它 运 行 结束 。 








与 MRy 1 中 的 JobTracker 不 同 ， 每 个 CoronaJobTracker 只 负责 管理 一 个 作业 。 





(3) CoronaTaskTracker (CTT) 





功能 类 似 于 YARN 中 的 NodeManager， 它 的 实现 重用 了 MRyv 1 中 TaskTracker 的 很 多 代码 〈 实 际 上 ，CoronaTaskTracker 类 继承 了 MRv 1 






































的 TaskTracker 类 ) : 一 方面 ， 它 通过 心跳 将 节点 资源 使 用 情况 汇报 给 ClusterManager;， 另 一 方面 ， 它 与 CoronaJobTracker 通 信 ， 以 获取 待 
运行 的 任务 和 汇报 正 运行 任务 的 状态 。 












































(4) ProxyJobTracker 
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ProxyJobTracker 是 一 种 离线 查看 作业 运行 信息 的 工具 。 当 一 个 作业 正在 运行 时 ， 用 户 可 通过 CoronaJobTracker 提 供 的 Web 服 务 查 看 作 
业 的 当前 运行 情况 ， 而 一 旦 作业 运行 完成 或 者 节点 处 于 离线 状态 时 ， 用 户 则 可 通过 ProxyJobTracker 查 看 作业 的 详细 运行 信息 ， 比 如 作业 
的 各 个 任务 执行 情况 、 作 业 Metrics、 作 业 Counter 等 。 
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2.Corona 的 RPC 协 议 与 序列 化 框架 


























(T 





括 客户 端 与 JobTracker 通 信 协 

















Hadoop Corona 是 基于 Hadoop 0.20 版 本 实现 的 ， 所 以 Hadoop 0.20 中 的 RPC 协 议 在 Corona 中 仍 被 采用 ， 




















议 JobSubmissionProtocol、TaskTracker 与 JobTracker 通 信 协 议 InterTrackerProtocol 和 Task 与 TaskTracker 之 间 的 通信 协议 TaskUmibiticalProtocolD| 
。 这 几 个 协议 在 第 4 章 均 有 介绍 ， 在 此 不 再 歼 述 。 除 了 在 MRv 1 中 已 存在 的 这 些 协议 ，Corona 又 增加 了 一 些 其 他 协议 ， 如 图 12-11 所 示 。 







































































口 ClusterManagerService: 它 是 采用 Thrif RPC 实 现 的 协议 ， 主 要 用 于 CoronaJobTracker、CoronaTaskTracker 与 ClusterManager 通 信 。 它 定 
义 了 CoronaJobTracker 申 请 和 释放 资源 、CoronaTaskTracker 汇 报 心跳 等 RPC 接 口 。 






















































































Q SessionDriverService: 该 协议 也 是 采用 Thrift RPC 实 现 的 。ClusterManager 通 过 该 协议 主动 将 信息 《如 新 分 配 的 资源 、 待 释放 的 资源 
等 ) 推送 给 CoronaJobTracker〔 而 不 是 让 CoronaJobTracker 轮 询 获 取 这 些 信息 ) 以 降低 延迟 。 






























































口 CoronaTaskTrackerProtocol: 该 协议 是 采用 Hadoop 自 带 的 RPC 框 架 实 现 的 。CoronaJobTracker 可 通过 该 协议 主动 将 命令 (如 启动 新 
任务 、 杀 死 任务 等 命令 ) 推送 给 CoronaTaskTracker 以 降低 延迟 而 不 是 像 MRv 1 那样 ，TaskTracker 通 过 心跳 周期 性 拉 取 JobTracker 命 




































































口 InterCoronaJobTrackerProtocol: 该 协议 是 采用 Hadoop 自 带 的 RPC 框 架 实 现 的 ， 远 程 模式 下 的 CoronaJobTracker 刚 启动 时 ， 将 通过 该 
协议 向 客户 端 ( 父 CoronaJobTracker) 汇报 它 所 在 节点 的 host 和 端口 号 ， 此 后 它 还 会 周期 性 向 客户 端 汇 报 心跳 ， 以 探测 父 CoronaJobTracker 
是 否 活着 ， 一 旦 发 现 父 CoronaJobTracker 失 败 ， 则 直接 退出 。 
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图 12-11 Corona‘ PAYRPCH IK 
[1] BARES UL: https://github.com/facebook/hadoop-20/tree/master/src/contrib/corona 
[2] Under the Hood: Scheduling MapReduce jobs more efficiently with Corona 

[3] #£Corona'#, Reduce Task 可 以 直接 与 CoronaJobTracker 通 信 ， 以 获取 已 经 运行 























成 的 Map Task 列 表 ， 而 不 必 通 过 CoronaTaskTracker 间 





























接 获 


12.4.2 Facebook Corona T E jit 


BIN HIS 











如 Hadoop Corona 的 工作 流程 。 


第 一 个 阶段 是 作业 
一 个 作业 的 Map Task 数 
模式 可 大 大 降低 小 作业 运行 延迟 。 另 外 一 种 是 远程 
源 ， 然 后 在 某 个 CoronaTaskTracker 上 


HE 














与 YARN 类 似 ， 当 








| FERS 











是 交 ， 实 际 上 就 是 启动 CoronaJobTracker 的 过 程 。 根 据 作业 大 
小 于 一 定 阔 值 ，CoronaJobTracker 将 直接 启动 在 客 
启动 模式 。 在 该 模式 下 ， 


启动 CoronaJobTracker。 这 种 模式 将 带 来 一 


























户 端 中 ， 这 被 称 为 本 地 





























定 的 运 
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12-12 ”Corona 中 的 本 地 启动 模式 





































































































\ 不 同 ，Corona JobTracker 采 | 


个 作业 后 ，Hadoop Corona 分 两 个 阶段 运行 该 作业 。 





















不 同 的 
启动 模式 ， 如 图 12-12 所 示 。 很 显然 ， 该 
客户 端 首先 为 CoronaJobTracker (向 ClusterManager) ! 


行 延迟 ， 本 小 节 将 重点 介绍 该 启动 模式 。 


TaskTracker 





启动 模式 。 如 果 














请 资 












Corona 




















第 二 个 阶段 是 资源 申请 与 任务 启动 。 在 该 阶段 中 ，CoronaJobTracker 不 断 向 ClusterManager 申 请 资源 ， 要 求 CoronaTaskTracker 启 动 任 
务 ， 并 监控 任务 的 运行 过 程 ， 直 到 所 有 任务 运行 完成 。 

接 下 来 ， 我 们 重点 介绍 大 作业 (Map Task A AF eB) 的 提交 和 运行 过 程 。 

1. 作 业 提 交 

作业 提交 过 程 实际 上 就 是 启动 CoronaJobTracker 的 过 程 。 为 了 与 MRv 1 兼容 ，Hadoop Corona 仍 由 JobClient 提 交 作 业 ， 但 里 面 的 代码 已 修 
改过 。JobClient 可 选择 将 作业 提交 到 MRyv 1 的 JobTracker 上 还 是 Corona 中 。 如 果 提 交 到 JobTracker 上 ， 则 作业 运行 在 MRv 1 中 ; A 





则 ， 


JobClient 内 部 会 创建 一 个 CoronaJobTracker 对 象 ， 然 后 | 

















CoronaJobTracker (i 














示 ， 大 致 可 分 别 以 下 几 个 步骤 ; 


步骤 1 










































































运行 在 转发 模式 下 ) 负责 提交 作业 。 之 后 过 程 如 








图 12-13 所 


CoronaJobTracker 内 部 创建 代理 对 象 RemoteJTProxy， 由 它 与 ClusterManager 和 CoronaTaskTiracker 通 信 ， 为 CoronaJobTracker G& 
行 在 远程 模式 下 ) 申请 资源 并 启动 它 。 
又 2 ”RemoteJTProxy 收 到 启动 CoronaJobTracker 的 请 求 后 ， 首 先 需 向 ClusterManager 申 请 资源 。 
上 又 3 ”ClusterManager 中 的 资源 调度 器 为 CoronaJobTracker 分 配对 应 的 资源 量 ， 并 返回 给 RemoteJTProxy。 
又 4 。 RemoteJTProxy 根 据 收 到 的 资源 描述 信息 (包括 资源 所 在 节点 ， 资 源 量 等 信息 





J 
Zz 


动 CoronaJobTracker。 


步骤 5 CoronaTaskTracker 3) 



































启动 CoronaJobTracker 后 ， 告 诉 RemoteJTProxy， 然 后 再 由 RemoteJTProxy 告 诉 客 





Sp 





) ， 与 对 应 的 CoronaTaskTracker 通 信 ， 要 求 它 启 








步骤 6 客户 端 得 知 CoronaJobTracker 启 动 成 功 后 ， 向 RemoteJTProxy 提 交 作业 ， 然 后 由 RemoteJTProxy 进 一 步 将 作业 提交 到 刚刚 启动 的 
CoronaJobTracker 上 。 


至 此 ， 一 个 作业 正式 提交 成 功 。 
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图 12-13 CoronaJobTracker 启 动 过 程 








需要 注意 的 是 ， 整 个 过 程 涉及 两 个 CoronaJobTracker: 第 一 个 运行 在 转发 模式 下 ， 负 责 提交 作业 和 转发 客户 端的 各 种 请 求 ， 第 二 个 运 
行 在 远程 模式 下 ， 负 责 申请 资源 和 监控 作业 运行 状态 。 








2. 资 源 申请 与 任务 启动 





























CoronaJobTracker 负 责 为 作业 申请 资源 ， 并 与 CoronaTaskTracker 通 信 ， 要 求 它 运行 Task。 总 之 ，CoronaJobTracker 功 能 如 下 。 





口 向 ClusterManager 申 请 资源 。 
































口 释放 资源 与 资源 重用 : ClusterManager 中 的 调度 器 支持 资源 抢占 ， 可 随时 命令 某 个 CoronaJobTracker 释 放 资 源 ， 另 
外 ，CoronaJobTracker 可 根据 需要 ， 自 行 决定 资源 是 不 是 重用 ， 即 某 个 任务 运行 完 后 ， 可 不 必 归 还 给 ClusterManager， 而 是 继续 分 配给 其 他 
任务 。 






































口 与 CoronaTaskTracker 通 信 ， 以 启动 新 任务 。 


口 任务 推测 执行 ， 可 参考 6.6 节 中 的 具体 介 








口 任务 容错 : 当 任务 执行 失败 后 ， 向 ClusterManager 重 新 申请 资源 ， 以 重新 运行 该 任务 。 























资源 申请 与 任务 启动 过 程 如 图 12-14 所 示 ， 主 要 步骤 如 下 : 


Se 


PIRI CoronaJobTracker| 各 ClusterManager 发 送 资源 请 求 。 








步骤 2 ” 当 某 个 CoronaTaskTracker 出 现 空闲 资源 后 ，ClusterManager 根 据 调度 策略 决定 将 该 资源 分 配给 哪些 作业 ， 并 将 资源 描述 发 送 给 
对 应 的 CoronaJobTracker。 


步骤 3 ”CoronaJobTracker 收 到 新 分 配 的 资源 后 ， 与 对 应 的 CoronaTaskTracker 通 信 ， 要 求 它 启动 任务 。 




















CoronaJobTracker 会 重复 以 上 三 个 步 又， 直到 所 有 任务 运行 完成 。 此 时 ，CoronaJobTiracker 通 知 ClusterManager 释 放 所 占用 的 资源 ， 并 退 
出 。 至 此 ， 一 个 作业 运行 完成 。 
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Al 12-14 ”CoronaJobTracker 资 源 申请 与 任务 启动 过 程 





12.4.3 YARN 与 Corona 对 比 


尽管 YARN 和 Corona 在 设计 目标 、 设 计 思 想 等 方面 是 一 致 的 ， 但 在 具体 实现 策略 上 仍 存在 很 多 不 同 之 处 。 表 12-1 对 比 了 YARN 和 
Corona 的 异同 。 





表 12-1 YARN 5 Corona 异同 点 比较 


Corona 
均 是 为 了 克服 MRv 1 在 扩展 性 、 可 靠 性 、 资 源 利 用 率 等 方面 存在 的 不 足 

设计 思想 均 是 将 JobTracker 中 作业 控制 和 资源 管理 两 个 功能 分 开 ， 由 不 同 的 进程 完成 

资源 调度 模型 均 是 基于 真实 资源 需求 量 的 调度 模型 ， 而 非 MRv 1 中 基于 slot 的 调度 模型 

降低 作业 延迟 机 制 让 小 作业 的 所 有 任务 直接 在 AM Container| 让 小 作业 的 CIT 直接 运行 在 客户 端 ， 但 任 
中 运行 务 的 运行 还 需 CIT 与 CM Fil CTT 交互 

通信 模型 拉 式 (pull-based) 通信 模型 ，AM 周期 性 | 推 式 (push-based) 通信 模型 ，CM 将 新 分 
向 RM 发 送 心跳 询问 是 否 分 配 到 了 新 的 资源 | 配 的 资源 直接 推送 给 CIT, ii CIT 会 进一步 

将 新 任务 推送 给 CTT 


设计 目标 









RPC 框架 Hadoop 自 带 的 RPC 框架 混合 使 用 Thrift RPC 和 Hadoop 自 带 的 RPC 
框架 
ATO ih 
在 线 升 级 采用 Zookeeper 实现 A T fith #e ClusterManager 暂停 服务 ， 升 级 
完毕 后 再 恢复 之 前 的 状态 
(2%) 
Corona 
Wy HEHE RM 可 靠 性 由 Zookeeper 保障 ，AM 出 现 故 | 截至 本 书 出 版 时 ，CM 尚 无 可 靠 性 保障 ， 
障 后 由 RM 重新 调度 运行 CIT 出 现 故 障 后 由 CM 重新 调度 运行 
调度 器 是 否 可 插 拔 可 以 ， 默 认 采 用 FIFO 调度 器 乌 不 可 以 ， 与 Fair Scheduler 耦合 在 一 起 


[1] ”YARN 中 的 FIFO 调 度 器 存在 Bug， 在 2.0.2-alpha 和 0.23.4 版 本 中 ， 己 将 默认 调度 器 暂时 切换 为 Capacity 


Scheduler， 具 体 参 考 : 
https://issues.apache.org/jira/browse/YARN- 137. 


12.5 


Apache Mesos 





Mesos [是 诞生 于 UC Berkeley 的 一 个 研究 项 目 。 它 的 设计 动机 是 解决 编程 模型 和 计算 框架 在 多 样 化 环境 下 ， 不 同 框架 间 的 资 


源 隔离 和 共享 问题 。 尽 管 它 的 直接 设计 动机 与 MRv 1 无 关 ， 但 它 的 架构 和 实现 策 
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进行 介绍 。 当 前 有 一 些 公司 正在 使 用 Mesos 管 理 集 群 资源 ， 比 如 国外 的 Twitter、 





12.5.1 Apache Mesos 基 本 框架 


如 图 12-15 所 示 ，Apache Mesos 由 四 个 组 件 组 成 。 接 下 来 将 详细 对 这 些 组 件 i 
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(1) Mesos-master 


























图 12-15 Mesos 的 基本 架构 





各 与 YARN 或 者 Corona 类 似 ， 因 此 ， 本 节 将 对 其 
E PY ky Sg (2) 等 。 





Spark 
Scheduler 





Mesos -slave 


Mesos-master 是 整个 系统 的 核心 ， 负 责 管理 整个 系统 中 所 有 资源 和 接 入 Mesos 的 各 种 计算 框架 (framework) ， 并 将 Mesos-slave 


上 的 资源 按照 某 种 策略 分 配给 框架 。 为 了 防止 Mesos-master 出 现 故 障 后 导致 集群 
并 通过 Zookeeper 进 行 管 理 。 当 主 Mesos-master 出 现 故 障 后 ，Zookeeper 可 马上 为 之 选择 一 个 新 的 主 Mesos-master。 

































































(2) Mesos-slave 


Mesos-slave 负 责 接收 并 执行 来 自 Mesos-master 的 命令 ， 并 定时 将 任务 执行 状态 ; 























不 可 月 








月 ，Mesos 人 允许 用 户 配置 多 个 Mesos-master， 


[ 报 给 Mesos-master。Mesos-slave 将 节点 上 资源 











的 使 用 情况 发 送 给 Mesos-master， 由 Mesos-master 中 的 Allocator 模 块 决定 将 资源 分 配给 哪个 Framework。 需 要 注意 的 是 ， 当 前 Mesos 
仅 考 虑 了 CPU 和 内 存 两 种 资源 。 当 用 户 提交 作业 时 ， 需 要 指定 每 个 任务 需要 的 CPU 个 数 和 内 存量 ， 而 当 任务 运行 时 ，Mesos-slave 





会 将 但 

















E 务 运行 在 包含 固定 资源 的 Linux Container 中 ， 以 达到 资源 隔离 的 效果 。 











(3) Framework-scheduler 








Framework 是 指 外 部 的 计算 框架 ， 如 MPI、MapReduce、Spak 等 。 这 些 计算 框架 可 通过 注册 的 方式 接 入 Mesos， 以 便 Mesos 进 
行 统一 管理 和 资源 分 配 。Mesos 要 求 接 入 的 框架 必须 有 一 个 调度 器 模块 Framework-scheduler， 该 调度 器 负责 框架 内 部 的 任务 调度 。 
一 个 Framework 在 Mesos 上 的 工作 流程 为 : 首先 通过 自己 的 调度 器 向 Mesos 注 册 ， 并 获取 Mesos 分 配给 自己 的 资源 ， 然 后 由 自己 的 
调度 器 将 这 些 资 源 分 配给 框架 中 的 任务 。 也 就 是 说 ， 整 个 Mesos 系 统 采 用 了 双 层 调度 框架 ;第 一 层 ， 由 Mesos 将 资源 分 配给 杠 

第 二 层 ， 框 架 自己 的 调度 器 将 资源 分 配给 内 部 的 各 个 任务 。 当 前 Mesos 支 持 三 种 语言 编写 的 调度 器 ， 分 别 是 CH+、Java 和 
Python。 为 了 向 各 种 调度 器 提供 统一 的 接 入 方式 ，Mesos 内 部 采用 C++ 实现 了 一 个 MesosSchedulerDriver〈 调 度 器 驱动 器 ) 。 
Framework 的 调度 器 可 调用 该 driver 中 的 接口 与 Mesos-master 交 互 ， 完 成 一 系列 功能 (如 注册 、 资 源 分 配 等 )。 






















































































































































































(4) Framework-Executor 





























Framework-Executor 主 要 用 于 启动 框架 内 部 的 任务 。 由 于 不 同 的 框架 ， 启 动 任务 的 接口 或 者 方式 不 同 ， 当 一 个 新 的 框架 要 接 
入 Mesos 时 ， 需 要 编写 一 个 对 应 的 Executor， 告 诉 Mesos 如 何 启 动 该 框架 中 的 任务 。 为 了 给 各 种 框架 提供 统一 的 执行 器 编写 方 
式 ，Mesos 内 部 采用 C++ 实现 了 一 个 MesosExecutorDriver 〈 执 行 器 驱动 器 ) 。Framework 可 通过 该 驱动 器 的 相关 接口 告诉 Mesos 启 动 
任务 的 方法 。 






























































[1] Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center. B.Hindman, A.Konwinski, M.Zaharia, A.Ghodsi, A.D.Joseph, 
R Katz, S.Shenker and I.Stoica, NSDI 2011, March 2011 
[2] https://github. con/douban/dpark/ 


12.5.2 Apache Mesos 资 源 分 配 






































































































































































































































Mesos 中 最 核心 的 问题 是 如 何 构建 一 个 兼 具 良好 扩展 性 和 性 能 的 调度 模型 以 支持 各 种 计算 框架 。 由 于 不 同 框架 可 能 有 不 同 的 
调度 需求 〈 这 往往 跟 它 的 编程 模型 、 通 信 模 型 、 任 务 依赖 关系 和 数据 放置 策略 等 因素 相关 ) ， 因 此 ， 为 Mesos 设 计 一 个 好 的 调度 
模型 是 一 项 极 具 挑 战 性 的 工作 。 

一 种 可 能 的 解决 方案 是 构建 一 个 具有 和 丰富 表 达能 力 的 中 央 调度 器 。 该 调度 器 接收 来 自 不 同 框架 的 详细 需求 描述 ， 比 如 资源 需 
求 、 任 务 调度 顺序 和 组 织 关 系 等 ， 然 后 为 这 些 任务 构建 一 个 全 局 的 调度 序列 。 但 是 ， 在 真实 系统 中 ， 由 于 每 种 计算 框架 具有 不 同 
的 调度 需求 ， 且 有 些 框架 的 调度 需求 非常 复杂 ， 因 此 ， 提 供 一 个 具有 丰富 表达 能 力 的 API 以 捕获 所 有 框架 的 需求 是 不 太 可 能 的 ， 
也 就 是 说 ， 访 方案 过 于 理想 化 ， 在 真实 系统 中 很 难 实现 。 


Mesos 提 供 了 一 种 简化 的 方案 
资源 分 配给 各 个 框架 ， 而 术 

















各 个 相 





(1) 资源 拒 





如 果 Mesos 为 某 个 框架 分 配 的 资源 不 符合 它 的 要 求 ， 则 框架 
EAR TE AZ AR IN RAS RAR A 





得 机 





匡 架 的 实际 资源 需求 的 了 解 ， 为 保证 杠 


绝 








(2) 资源 过 滤 


每 次 发 生 











额外 的 通信 了 




















(3) 资源 回收 





如 果菜 个 框 








给 其 他 框架 。 


与 YARN 和 Corona 类 似 ，Mesos 也 采 月 


FE 下， 还 


E 资 源 调 度 时 ，Mesos-master 均 需要 
于 销 会 使 得 调度 性 能 变 得 低 效 。 为 避免 不 必要 的 通 
大 于 的 Mesos-slave’ 或 者 “位 于 





: 将 资源 调度 的 控 和 
匡 架 内 部 调度 器 则 根据 一 些 个 








| 授权 给 各 个 杠 











架 在 一 定 的 时 间 内 没有 为 分 配 的 资源 返 


ab str J 
架 能 高 效 


能 够 保证 Mesos 设 计 简单 和 











也 于 











架 。Mesos 负 责 按 照 


取 到 自己 需要 的 资源 ， 它 提供 了 
























































调度 算法 (Dominant Resource Fairness, DRF) l. 


源 的 调度 。1 


在 DRF 算 法 中 ， 将 所 需 份 额 〈 资 源 比 例 ) 最 大 的 资源 称 为 主 资源 ， 而 DRF 的 
资源 上 ， 进 而 将 多 维 

















于 DRF 被 证 明 非 常 适 



































合 应 





日 了 基于 真实 资源 需求 量 








该 算法 扩 


isi 


性 化 的 需求 将 分 配 到 的 资源 进一步 分 配给 各 个 作业 。 考 虑 到 Mesos 缺 





























可 以 拒绝 接受 该 资源 ， 直 到 出 现 满足 自己 需求 的 资源 。 
有 良好 的 扩展 性 。 





些 简 单 的 策略 〈 比 如 FIFO, Fair 等 ) 将 
少 对 

三 个 机 制 ; 
该 机 制 使 



































] 于 多 资源 和 复杂 需求 的 环境 


大 | 











言 ，Mesos 提 供 了 资源 过 
F 特定 列表 中 的 Mesos-slave" 上 的 资源 。 


回 对 应 的 任务 ， 则 Mesos 将 回 





要 与 Framework-scheduler 进 行 通信 ， 如 果 有 些 框架 总 是 拒绝 某 些 节 


点 上 的 资源 ， 那 么 









































寸 泪 机制， 允许 框架 只 接收 来 自 " 剩 余 资源 量 
收 为 其 分 配 的 资源 ， 并 将 这 些 资源 重新 分 配 

















展 了 最 大 最 小 公平 (MaxMin Fairness) 3% P, 


的 调度 模型 。 为 了 支持 多 维 资源 调度 ，Mesos 采 用 了 主 资 源 公平 
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能 够 支持 多 维 
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DX 














此 被 越 来 越 多 的 系统 采用 ， 包 括 Apache YARN |! 。 
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REL UU eR EK RDNA FRAMA PE 








资源 调度 问题 转化 为 单 资 源 调度 问题 ， 即 DRF 总 是 最 大 化 所 有 主 资源 








FP 最 小 的 。 其 算法 伪 代 码 如 下 : 





function void 


Re = ry 





DRFSchedul 
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的 资源 ， 初 始 值 为 0 
EA) i 的 主 资源 所 需 





初始 化 为 0 


份额 ， 
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IE SCHO 


// 将 资源 分 配给 


Ce=C+Di 
Ui Uy 
Si 
else 


return; 
end if 


=max™ 
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资源 量 }; 


=1..n) // 分 配给 用 








户 i 的 资源 ， 初 始 化 为 0 


end function 





【实例 】 假 设 系统 中 共有 9 CPUs 和 18 GB RAM， 有 两 个 用 户 ( 或 者 框架 ) 分 别 运 行 了 两 种 任务 ， 需 要 的 资源 量 分 别 为 <1 
CPU，4GB> 和 <<3 CPUs, 1 GB> 。 对 于 用 户 A， 每 个 任务 要 消耗 总 CPU 的 119《〈《 份 额 ) 和 总 内 存 的 29， 因 而 A 的 主 资源 为 内 存 ; 
对 于 用 户 B， 每 个 任务 要 消耗 总 CPU 的 113 和 总 内 存 的 M18， 因 而 B 的 主 资源 为 CPU。DREF 将 最 大 化 所 有 用 户 的 主 资源 ， 有 具体 分 配 过 
程 如 表 12-2 所 示 。 最 终 ，A 获 取 的 资源 量 为 <3 CPUs，12 GB>， 可 运行 3 个 任务 ;而 B 获 取 的 资源 量 为 <6 CPUs，2 GB>>， 可 运 
行 2 个 任务 。 











































































































表 12-2 DRF 算法 的 调度 序列 


调度 序列 CPU 使 用 量 RAM 使 用 量 








资源 份额 EE 资源 份额 资源 份额 主 资源 份额 
User B 1/18 
User A 5/18 
UserA 9/18 
User B 10/18 
UserA 14/18 





[1] Dominant Resource Fairness: Fair Allocation of Multiple Resources Types. A.Ghodsi, M.Zaharia, B.Hindman, A.Konwinski, S.Shenker, and 
LStoica, NSDI 2011, March 2011 

[2] Max-Min Fairness (Wikipedia) : http://en. wikipedia.org/wiki/Max-min fairness 

[3] https//issues. apache. org/jira/browse/Y ARN-2 


12.5.3 MapReduce 与 Mesos 结 合 











1 于 Hadoop MapReduce 的 JobTracker 和 TaskTracker 与 Mesos 模 型 中 的 Framework-scheduler 和 Executor 在 设计 上 是 完全 对 应 的 ， 因 
此 ， 只 需 修改 少量 代码 便 可 让 MapReduce 运 行 于 Mesos 之 上 。 












































为 了 让 Mesos 支 持 MapReduce， 需 为 其 编写 Scheduler 和 Executor 两 个 组 件 。 它 们 的 作用 如 下 : 








(1) Scheduler 











Mesos 利 用 了 Hadoop 调 度 器 可 插 拔 的 特性 ， 重 新 实现 了 一 个 可 接 入 Mesos 的 调度 器 MeosScheduler， 以 实现 框架 注册 、 资 源 分 配 
等 功能 。 

















(2) Executor 








Mesos *yHadoop KI, Y —7SExecutor——FrameworkExecutor. if it i%Executor, Mesos 可 控制 TaskTracker 的 启动 或 停止 。 比 如 ， 如 
果 一 定时 间 内 没有 任务 运行 ，Mesos 会 关闭 某 些 节点 上 的 TaskTracker。 




















为 了 使 Hadoop 能 运行 于 Mesos 之 上 ，JobTracker 启 动 时 通过 调度 器 向 Mesos 注 册 ， 这 之 后 ， 资 源 分 配 过 程 如 图 12-16 所 示 ， 大 致 分 
为 以 下 几 个 步 又; 








Mesos Porting layer Hadoop 













Mesos -master JobTracker 





TaskTracker TaskTracker 





Mesos-slave Mesos -slave 








Ps 














12-16 Hadoop 在 Mesos 上 工作 流程 











步骤 1 Mesos-slave| 避 Mesos-master 汇 报 自己 的 资源 使 用 情况 ， 当 前 支持 的 资源 类 型 包括 CPU 和 内 存 两 种 。 











步骤 2 ”如 果 Mesos-slave 上 有 空闲 资源 ，Mesos-master 会 按照 一 定 的 策略 将 资源 分 配给 当前 向 其 注册 的 框架 。 如 果 分 配给 

















Hadoop， 则 告诉 其 调度 器 ， 它 会 按照 一 定 的 策略 选 出 若干 Hadoop 任 务 并 暂时 缓存 起 来 〈 稍 后 对 应 的 TaskTracker 通 过 心跳 领取 这 些 
任务 ， 见 步骤 $) ， 并 返回 一 系列 Mesos-task 列 表 〈 该 任务 的 作用 仪 是 在 Hadoop 任 务 正式 启动 之 前 为 它 准备 资源 ， 并 不 用 于 真正 的 
计算 ) ， 其 中 每 个 Mesos-task 会 对 应 一 个 Hadoop 任 务 。 








































































































步骤 3 ”JMesos-master 将 Mesos-task 列 表 发 送 给 对 应 的 Mesos-slave。 









































步骤 4 Mesos-slave 收 到 一 个 Mesos-task 后 ， 检 查 它 是 否 是 收 到 的 第 一 个 来 自 Hadoop 框 架 的 任务 ， 如 果 是 ， 则 通过 Executor 为 其 
启动 TaskTracker。 








Si 


又 5 与 正常 的 Hadoop 集 群 一 样 ，TaskTracker 加 JobTracker 报 心跳 ， 以 领取 新 的 计算 任务 〈 即 步骤 2 中 缓存 起 来 的 任务 ) 。 




















fa 

















步骤 6 JobTracker 收 到 来 自 TaskTracker 的 心跳 后 ， 通 过 调度 器 为 其 分 配 任务 。 需 要 注意 的 是 ， 此 时 调度 器 分 配 多 少 任务 并 不 取 
决 于 该 TaskTracker 上 有 多 少 空闲 的 slot， 而 是 取 诀 于 Mesos 为 其 分 配 的 资源 量 〈 在 步 又 2 中 分 配 的 资源 量 
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ART JobTracker 将 新 分 配 的 任务 返回 给 对 应 的 TaskTracker。 

















步骤 8 TaskTracker 收 到 新 任务 后 ， 启 动 这 些 任务 。 需 要 注意 的 是 ， 这 些 任 务 执行 过 程 中 的 状态 更 新 不 仅 会 告诉 TaskTracker， 


也 会 通过 Executor 汇 报 给 Mesos。 


























12.6 ”小结 


本 章 介绍 了 下 一 代 MapReduce 的 基本 设计 思想 以 及 常见 的 三 个 实现 : YARN、Corona 和 Mesos。 

















YARN 是 Apache 的 下 一 代 MapReduce 框 架 。 它 的 基本 设计 思想 是 将 JobTracker 拆 分 成 两 个 独立 的 服务 : 一 个 全 局 的 资源 管理 器 























ResourceManager 和 每 个 应 用 程序 特有 的 ApplicationMaster。 其 中 ，ResourceManager 负 责 整 个 系统 的 资源 管理 和 分 配 ， 而 
ApplicationMaster 则 负责 单个 应 用 程序 的 管理 。 





















































与 YARN 一 样 ，Corona 也 是 将 JobTracker 拆 分 成 了 两 个 独立 的 服务 : 一 个 全 局 的 资源 管理 器 ClusterManager 和 每 个 应 用 程序 特 
































有 的 CoronaJobTracker。 其 中 ，ClusterManager 负 责 整 个 系统 的 资源 管理 和 分 配 ， 而 CoronaJobTracker 则 负责 单个 应 用 程序 的 管理 。 


















































Mesos 诞 生 于 UC Berkeley 的 一 个 研究 项 目 。 它 的 设计 动机 是 解决 编程 模型 和 计算 框架 在 多 样 化 的 环境 下 的 框架 间 资 源 隔离 和 





















































共享 问题 。 尽 管 它 不 是 直接 从 MRv 1 衍化 而 来 的 ， 但 它 具 备 了 下 一 代 MapReduce 的 基本 特征 。 








尽管 YARN、Corona 和 Mesos 诈 生 于 不 同 的 公司 或 者 研究 机 构 ， 但 它们 的 架构 却 大 同 小 异 ， 表 12-3 给 出 了 它们 内 部 基本 组 件 








的 对 应 关系 。 


表 12-3 YARN、Corona 和 Mesos 基本 组 件 对 应 关系 


Resource Manager | Cluster Manager Mesos Master 负责 整个 集群 的 资源 管理 和 调度 。 


Mesos Slave 负责 单个 节点 的 资源 管理 (资源 隔离 、 资 源 使 
Node Manager Corona TaskTracker FAIR ED. FEB ERE as, RES) 和 任务 


Framework- executor | Framework- executor | 运行 进度 汇报 等 。 


i 负责 单个 应 用 程序 的 管理 和 资源 的 二 次 调度 
Application Master | Corona JobTracker | Framework-scheduler Pi po Mn fae eit R roe py 的 二 次 调度 




















随 着 应 用 需求 的 多 样 化 和 数据 量 的 增加 ， 下 一 代 MapReduce 必 将 逐渐 替代 MRv 1， 被 越 来 越 多 的 公司 采用 。 
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附录 A ”安装 Hadoop 过 程 中 可 能 存在 的 问题 及 解决 方案 


问题 1 在 Windows 中 运行 Hadoop 时 ， 出 现 以 下 异常 








ERROR security.UserGroupInformation (UserGroupInformation.java: doAs (1086) ) -PriviledgedActionException as 
dong cause: java.io.IOException: Failed to set permissions of path: D:\hadoop\hadoop- 
1.0.0\build\test\mapred\staging\trss1723775845\.staging to 0700 











【产生 原因 】 























由 于 Hadoop 1.0.0 中 独特 的 修改 目录 权限 趾 的 方法 ， 使 得 编译 后 的 jar 包 不 能 直接 运行 于 Windows 环 境 。 




















【解决 方法 】 





最 简捷 的 方法 是 ， 对 src\core\oraapache\hadoop\ 人 8\FileUtLjava 代 码 做 以 下 修改 (注释 三 行 代码 〉: 








private static void checkReturnValue (boolean rv, File p, 
FsPermission permission 
) throws IOException { 


iE Cl ews d 

//throw new IOException ("Failed to set permissions of path: "+p+ 
// 

"to"4 

// 


String.format ("%S040", permission.toShort()) ) ; 


}} 








修改 之 后 重新 编译 Hadoop 源 代码 。 





问题 2 Hadoop eclipse plugin 报 错 :“Eror: failure to login” 








【产生 原因 】 
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直接 编译 代码 后 生成 的 jar 包 由 








缺少 一 些 依赖 的 地 文件 ， 不 能 直接 使 用 。 
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【解决 方法 】 








对 配置 文件 进行 部 分 修改 ， 修 改 的 文件 涉及 src/contrib/eclipse-plugin 目 录 下 的 build.xml 和 META-INF/MANIFEST.MF 文 件 。 








修改 build.xml 如 1 下 在 文件 末尾 添加 以 下 内 容 》: 








<copy file="${hadoop.root}/lib/commons-configuration-1.6.jar"todir="${build.dir}/lib"verbose="true"/> 
<copy file="${hadoop. root}/1lib/commons-lang-2.4.jar"todir="$ {build.dir}/lib"verbose="true"/> 

<copy file="${hadoop. root}/lib/jackson-core-asl-1.0.1.jar"todir="${build.dir}/lib"verbose="true"/> 
<copy file="${hadoop.root}/lib/jackson-mapper-asl-1.0.1.jar"todir="$ {build.dir}/lib"verbose="true"/> 
<copy file="${hadoop. root}/lib/commons-httpclient-3.0.1.jar"todir="${build.dir}/lib"verbose="true"/> 





将 META-INF/MANIFEST.MF 文 件 中 的 Bundle-ClassPath 属 性 修改 为 : 








Bundle-ClassPath: classes/, lib/hadoop-core.jar, lib/commons-configuration-1.6.jar, lib/commons-lang-2.4.jar, 
lib/jackson-core-asl-1.0.2.jar, lib/jackson-mapper-asl-1.0.2.jar, lib/commons-httpclient-3.0.1.jar 




















经 过 上 面 编译 之 后 ， 产 生 的 jar 包 位 于 build/contrib/eclipse-plugin 目 录 下 ， 将 该 jar 包 拷贝 到 Eclipse 的 plugins 目 录 下 ， 重 启 Eclipse 即 
































问题 3 ”Windows 环 境 下 使 用 Cygwin 终 端 启动 Hadoop 时 ， 出 现 错误 “ssh: connect to host localhost port 22: Connection refused” 








【产生 原因 】 












































Windows 系 统 下 ，ssh 命 令 需 要 管理 员 权 限 才 能 使 用 。 








ag 





【解决 方案 】 





方案 一 ”永久 修改 ssh 启 动 权限 











HEL: Windows 环 境 下 ， 依 次 选择 开始 一 运行 一 输入 services.msc。 











步 





又 2: 右 击 CYGWIN sshd， 并 依次 选择 属性 一 登录 一 此 账 
限 ) 一 输入 密码 一 确定 。 
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E CYGWIN sshd 服 务 。 


























方案 二 ”以 管理 员 身 份 打 开 Cygwin 终 端 
































右 击 Cygwin 可 执行 文件 ， 单 击 “ 以 管理 员 身 份 运行 ”。 

















[1] https//Assues. apache.org/jira/browse/MAPREDUCE-3555 





户 一 浏览 一 高 级 一 立即 查找 一 选择 账 




















户 名 〈 必 须 为 管理 














附录 B Hadoop 默 认 HTTP 端 口号 以 及 HTTP 地 址 





为 了 便于 用 户 通过 这 些 Web UI 查看 Hadoop 当 前 运行 状态 ，Hadoop 对 外 提供 了 一 些 访问 URL。 这 些 URIL 的 默认 端口 号 》 
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表 B-1 所 示 。 








表 B-1 默认 端口 号 汇总 


Hadoop 模块 守护 进程 默认 端口 号 配置 参数 
50070 dfs. http.address 
HDFS SecondNameNode 50090 dfs.secondary.http.address 
JobTracker mapred.job.tracker.http.address 
MapReduce 
TaskTracker mapred.task.tracker.http.address 

















Hadoop 守 护 进程 向 用 户 提供 的 HTTP 地 址 有 以 下 几 项 。 




















O/logLevel: 查看 和 修改 Hadoop 源 代码 类 的 输出 日 志 级 别 。 



































DAstacks: 显示 当前 所 有 线程 的 栈 轨迹 ， 主 要 用 于 调试 。 


O/metrics: 显示 Hadoop 中 所 有 Metrics 信 息 。 
































口 显示 JobTiracker (ip7910.10.10.100) 所 在 机 器 上 Hadoop 产 生 的 日 








http://10. 10.10.100: 50030/logs 
口 显示 TaskTracker (jp 为 10.10.10.111) 上 的 Metrics 信 息 : 


httpV10. 10.10.111: 50060/metrics 


Oog: 显示 日 志 目录 中 的 所 有 日 志文 件 ， 可 供用 户 查 看 日 志 或 者 下 载 
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日 志 使 用 。 举 例 说 明 
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[1] Hadoop Jia 是 Hadoop 的 项 目 管理 系统 ， 通 过 它 可 追踪 一 些 问题 的 解决 过 程 。 比 如 问题 'HADOOP-7775”， 可 通过 网 
hit “https:/issues.apache. org/jira/browse/HADOOP-7775"2& » 


